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Systems  and  cultures  have  evolved  over  time  into  the  processes 
and  products  which  drive  current  businesses.  The  years  of 
evolution  have  often  resulted  in  business  processes  plagued  with 
islands  of  automation,  patchwork  integration,  massive 
redundancies,  and  organizational  stovepipes. 

The  continuous  improvement  approaches  of  Total  Quality 
Management  (TQM)  have  not  provided  the  breakthrough  strategies 
required  to  quickly  transform  organizations  to  effectively  compete 
in  the  1990's  and  beyond.  As  noted  author  Tom  Peters  wrote 
"There  will  be  two  kinds  of  companies  in  the  future  —  the  quick  and 
the  dead”. 

As  a  result  of  the  necessity  for  speed  of  change,  a  new  paradigm 
termed  Business  Process  Reengineering  (BPR)  was  born  which 
addresses  the  fundamental,  radical,  and  process  focused  strategies 
required  to  help  organizations  quickly  gain  competitive  edge. 

Both  government  and  commercial  organizations  have  reacted  to 
the  reengineering  revolution  by  adopting  the  term  and  embarking 
on  a  perilous  journey  towards  total  business  transformation.  The 
consulting  and  contractor  communities  quickly  jumped  in  line, 
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The  Result 


The  Questions 


The  Value 


recasting  themselves  from  integrators  and  quality  improvement 
experts  into  reengineers. 

With  a  multitude  of  materials  and  consultants  explaining  what  to 
do  and  few  explaining  how  to  do  it,  the  track  record  of  BPR  has 
suffered  some  early  set-backs.  For  every  organization  claiming 
success,  there  is  another  claiming  failure.  A  variety  of  tools  and 
techniques  have  emerged  to  further  complicate  the  marketplace, 
each  virtually  untested  in  meeting  the  broad  reaching  needs  of 
BPR. 


As  with  most  new  paradigms,  the  confusion  and  misinterpretation 
associated  with  BPR  has  been  widespread,  yielding  questions  such 


What  is  BPR  and  how  does  it  relate  to  TQM? 


Why  are  early  BPR  efforts  being  referred  to  as 
failures? 


How  do  we  define  a  business  process  in  a  manner  that 
is  clear,  consistent,  and  repeatable? 


restructuring, 


Isn't  BPR  too  risky  for  my  organization?  After  all,  we 
have  been  able  to  stay  in  business  for  the  last  20  years 


The  merits  of  rethinking  business  processes  are  difficult  to 
question,  yet  the  resulting  transformation  is  still  difficult  for  many 
organizations  to  accept.  While  the  questions  highlighted  in  the 
previous  paragraphs  represent  a  broad  spectrum  of  community 
interests,  the  most  fundamental  question  is  that  of  VALUE. 

How  can  BPR  strategies  be  used  to  increase  the  value 
of  processes  and  products  for  my  business  ? 
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The  Book 


This  book,  entitled  "Business  Process  Reengineering  for  Quality 
Improvement" ,  focuses  on  answering  some  of  the  most  frequently 
asked  questions  relating  to  Business  Process  Reengineering.  In 
addition,  the  book  provides  valuable  insight  into  what  must  be 
done  to  successfully  complete  a  reengineering  effort  along  with 
examples  and  guidance  on  how  such  tasks  can  be  effectively 
completed. 
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1.1.  PURPOSE 

The  purpose  of  this  document  is  to  integrate  research  and 
experience  on  the  topic  of  Business  Process  Reengineering  (BPR) 
into  a  State-of-the-Art  Report  (SOAR).  To  be  successful,  this 
document  must: 

•  discuss  critical  factors  affecting  successful  BPR  efforts 

•  improve  awareness  of  organizations  and  individuals 
involved  in  BPR  efforts 

•  provide  guidelines  (strategies  and  methodologies)  for 
successful  implementation  of  BPR 

The  goal  is  not  to  establish  a  new  approach  to  reengineering,  but  to 
integrate  existing  methodologies,  concepts,  and  strategies  into  a 
single  document  which  improves  reader  understanding  of  the  BPR 
paradigm.  The  content  of  this  document  has  been  gathered  from 
personal  experience,  as  well  as  research  on  BPR  efforts,  literature 
from  industry  experts,  and  customer  feedback. 

Throughout  the  course  of  this  document,  examples  will  be  used  to 
highlight  the  use  of  BPR  in  improving  both  process  and  product 
quality. 

Who  Should  Read  The  document  is  intended  to  serve  the  following  customer 

communities: 

•  managers  attempting  to  perform  business  process 
reengineering  within  their  organization 

•  staff  involved  in  and  wishing  to  better  understand  business 
process  reengineering 

•  consultants  wanting  further  guidance  on  structured 
approaches  to  business  process  reengineering 

1.2.  document  Overview 

Throughout  this  document,  reference  is  made  to  the  concept  of  a 
Process  Management  Life  Cycle  (PMLC).  Such  a  cycle  is  used  to 
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describe  the  stages  in  the  life  of  a  process,  as  shown  in  the 
following  diagram. 


Figure  1.2-1.  Process  Management  Life  Cycle  (PMLC) 


The  Process  Management  Life  Cycle  (PMLC)  represents  the 
foundation  for  organization  and  presentation  of  information  within 
this  text. 

1.2.1.  Document  Organization 

Since  the  focus  of  this  document  is  reengineering,  the  document 
has  been  organized  to  walk  the  reader  through  a  series  of  chapters 
focusing  on  reengineering  project  stages  as  illustrated  in  the 
following  diagram.  While  the  diagram  illustrates  reengineering  as  a 
formalized  and  sequential  approach,  successful  application  of 
reengineering  requires  that  strategies  be  implemented  in  a  flexible 
manner. 


Transformation 


Innovation  &  . 
Redesign 


Preparation 


Identification  , 
&  Assessment 


Reengineering 


Engineering 


Retirement 


Evolution 


Figure  1.2-2.  Reengineering  Project  Stages 


Where  possible,  examples  have  been  provided  to  further  guide  user 
understanding.  A  brief  overview  of  the  information  presented  in 
each  chapter  is  provided  in  the  following  list. 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


CHAPTER  1.  INTRODUCTION 


Page  5 


•  Chapter  1.  Introduction  -  Provides  an  overview  of  the 
organization  and  content  of  this  document  as  well  as  a 
description  of  common  concepts,  critical  factors  and 
distinctions  used  throughout  this  document. 

•  Chapter  2.  Preparation  -  Gives  insight  into  those 
components  required  to  initiate  a  reengineering  effort, 
including  defining  success  in  terms  of  goals  and  targets,  and 
gaining  management  commitment. 

•  Chapter  3.  Identification  &  Assessment  -  Provides 
approaches  for  defining,  assessing  and  selecting  business 
processes  to  be  reengineered.  This  assessment  provides 
guidance  relating  to  alignment  of  business  process  impacts 
with  business  goals  and  targets  for  success. 

•  Chapter  4.  Innovation  &  Redesign  -  Describes  the  steps 
required  to  visualize,  analyze,  decompose,  and  redesign 
(reengineer)  a  business  process  in  order  to  achieve  business 
goals  and  targets.  Key  aspects  include  a  discussion  of  both 
technical  and  social  (organizational  culture)  redesign  of 
processes. 

•  Chapter  5.  Transformation  &  Evolution  -  Describes  the  steps 
of  transforming  a  business  process  and  provides  insight  into 
the  continuous  process  improvement  tools  and  techniques 
common  to  a  Total  Quality  Management  (TQM) 
environment  that  are  required  to  evolve  processes  in  a  value- 
added  manner. 

•  Appendices.  Reengineering  Toolbox  -  Provides  valuable 
references  to  terms,  documents,  articles,  data  sources,  and 
tools  that  can  be  used  to  support  reengineering. 

1.2.2.  Document  "Eye"  Cons 

A  set  of  icons  or  graphical  tabs  are  used  throughout  the  left  hand 
margin  of  this  document  to  ease  the  readability  and  aide  the  reader 
in  quick  reference.  Where  possible,  common  icons  are  utilized  to 
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I  Case  Study 
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represent  a  particular  area  of  interest  as  described  in  the  following 
paragraphs. 

Throughout  this  document,  the  icon  shown  to  the  left  of  this 
paragraph  is  used  to  highlight  recommended  actions.  Specifically, 
the  icon  identifies  when  information  should  be  recorded  by 
users/readers  into  a  Process  Management  Notebook  (PMN).  The 
authors  understand  that  a  variety  of  automated  and  manual 
approaches  may  be  utilized  to  construct  and  maintain  a  PMN  and 
therefore  focus  attention  on  "what"  should  be  included  and  not 
"how".  While  the  PMN  is  referenced  throughout  this  document, 
Chapter  5  entitled  "Transformation  and  Evolution"  summarizes  the 
contents  and  usage  of  the  PMN.  The  PMN  summary  may  be  useful 
in  the  definition  and  selection  of  appropriate  approaches  (manual 
and  automated)  for  process  management. 

Concepts  are  often  difficult  to  understand  or  visualize  without  real- 
world  examples.  The  icon  shown  to  the  left  of  this  paragraph  is 
used  throughout  the  document  to  highlight  examples  by  following 
the  actions  of  a  practicing  company  through  the  stages  of  BPR, 
including  both  what  actions  were  taken  and  how  actions  were 
implemented.  Examples  are  not  just  intended  to  represent  that  of 
"best  practices",  but  are  meant  to  convey  both  what  worked  and 
often  what  didn't  work  in  a  practicing  business  enterprise. 

The  example  company  used  throughout  this  document  is  CSK 
Technical,  Inc.,  referred  to  as  "CSK",  which  is  briefly  described  in 
the  following  paragraph. 

CSK  is  a  small  business  and  turnkey  supplier  of  water 
treatment  systems.  CSK  operates  from  a  10,000  square 
foot  manufacturing  facility  located  in  Western  New 
York.  In  operation  for  over  30  years,  CSK  specializes 
in  custom  designed  systems,  each  engineered  to  meet 
the  individual  needs  of  a  specific  customer.  In  early 
1994,  CSK  initiated  business  process  reengineering 
efforts  as  a  means  of  achieving  dramatic  improvement 
in  processes  with  respect  to  business  goats. 
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Where  concepts  or  methodologies  are  described  in  greater  detail 
elsewhere  in  the  document,  the  icon  shown  to  the  left  of  this 
paragraph  is  used  as  a  pointer  to  the  specific. 

1.2.3.  FORMALISMS 

A  variety  of  diagramming  techniques  and  formalisms  are  used 
within  this  document.  Such  variations  are  used  to  improve  visual 
presentation,  expose  the  reader  to  alternative  conventions,  and 
convey  the  message  that  the  thought  process  is  much  more  critical 
than  formal  or  rigid  presentation. 

1.2.4.  Graphical  highlights 

The  left  margin  may  also  be  used  to  present  graphical  highlights 
and  pictures,  which  may  aide  the  reader  in  understanding  the 
concepts  presented  and/or  improve  the  visual  presentation  of  the 
publication. 

1 .3.  WHAT  IS  BUSINESS  PROCESS  REENGINEERING? 

The  confusion  associated  with  any  new  paradigm  is  often 
staggering.  As  a  result,  many  organizations  tend  to  miscast 
strategies  or  generalize  meanings.  For  example,  the  March  1995 
issue  of  Readers  Digest  provided  the  following  overview  of  new 
terms. 

RMBgitmnilg.  -  The  principle  slogan  of  the  Wsused 
to  describe  any  and  all  corporate  strategies.  iMBBIBB 

Restructuring  -  A  simple  plan  institutionalized  from 
above,  in  which  workers  are  rightsized,  downsized, 
surplused,  or,  in  the  business  jargon  of  you're  fired. 

YMsu  |  Top  management’s  heroic  guess  about  the  §§j| 
future,  easily  imprinted  on  mugs,  Tshirts,  and  posters. 

While  many  of  the  definitions  are  meant  to  be  humorous,  they  are 
likely  to  be  more  representative  of  what  many  subjected  to  such 
paradigms  truly  believe. 
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Definition  of  Business 
Process  Reengineering 


Reengineering  is 
Inevitable 


Probably  the  most  widely  used  definition  for  Business  Process 
Reengineering  (BPR)  is  that  provided  by  Hammer  and  Champy  in 
their  best-selling  book  "Reengineering  the  Corporation"  which 
reads  as  follows. 


pi*  . . 

The  fundamental  rethinking  and  \ 


such  as  cost,  quality,  service, 


..^rovemems 
,  r„;ormance, 


Early  estimates  indicate  that  over  70  percent  of  organizations  are 
currently  involved  in  some  form  of  Business  Process 
Reengineering  (Redesign).  Furthermore,  experts  estimate  that 
approximately  75%  to  85%  of  BPR  efforts  fail.  Even  with  the 
difficulties  experienced  by  early  reengineering  efforts,  most  large 
consulting  firms  expect  the  trend  towards  BPR  to  continue,  and 
most  corporations  are  expected  to  increase  emphasis  on  BPR. 
Why? 

Today's  emphasis  on  downsizing  (we  prefer  the  term  rightsizing), 
automating,  and  reorganizing  is  a  necessity  with  growing 
competition  and  increasing  focus  on  customer  service.  This  trend 
of  change  represents  a  form  of  reengineering  (however 
unstructured)  that  will  continue  for  several  years  to  come. 
Organizations  no  longer  can  afford  to  rest  on  previous 
accomplishments,  past  products,  or  weak  competition  to  keep 
market  share,  they  must  achieve  operational  excellence  at  a 
minimum  cost.  According  to  an  interview  presented  in  the  March 
1995  issue  of  Performance  magazine,  Michael  Hammer  (often 
credited  with  discovering  reengineering)  states  that  a  key  reason  is 
"inevitability".  He  further  states  that  "You  have  to  make  people 
understand  that  reengineering  is  not  something  that  might  happen, 
or  something  we're  asking  for  a  debate  on.  This  is  going  to 
happen. "  In  response  to  the  high  failure  rate  associated  with  BPR, 
Hammer  states  that  "when  reengineering  doesn't  work  it's  because 
it's  not  done  right. " 
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While  it  is  clear  that,  to  date,  BPR  has  been  more  of  an  art  than  a 
science,  this  book  will  attempt  to  communicate  key  factors 
affecting  the  success  of  BPR  efforts  and  offer  a  structured 
approach  leaning  toward  reengineering  as  a  scientific  form. 

Business  Enterprise  Readers  should  also  understand  that  business  process  reengineering 

focuses  on  processes  with  respect  to  the  business  enterprise.  The 
business  enterprise  represents  the  collection  of  all  processes  and 
activities  which  are  included  within  the  boundaries  of  the  business. 
While  there  are  many  loose  definitions  for  processes,  a  " business 
process "  has  a  more  distinct  definition  which  is  clearly  stated  in 
Chapter  3  (section  3.1)  of  this  text. 


1.4.  Engineering  vs.  Reengineering 


Reengineering  implies  that  processes  were  engineered  in  the  first 
place.  In  general,  processes  are  conceived  upon  business  start-up  or 
integration  of  new  business  requirements  and  have  evolved  to 
reach  their  current  state  of  design.  Rethinking  of  existing  process 
designs  after  a  period  of  evolution  will  often  yield  new  process 
designs  which  may  seem  radical  in  nature.  The  following  figure 
illustrates  the  relationships  between  engineering,  evolution,  and 
reengineering. 


Engineer 

(Think) 


Evolve 

(Adapt) 


Reengineer 

(Rethink) 


Conception 
The  origination  of 
something. 


Evolution 

The  process  of  gradual  and 
relatively  peaceful  social, 
political,  and  economic 
advance.  The  process  of 
change  in  a  certain  direction. 


Revolution 
A  sudden,  radical,  or 
complete  change. 


Figure  1.4-1.  Engineering  vs.  Reengineering 
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Legacy  Business 
Processes 


Evolution  vs.  Revolution 


In  addition  to  the  radical  perception  of  a  new  process  design,  the 
implementation  of  the  new  design  is  often  more  complicated  than 
"clean-slate"  engineering  due  to  difficulties  associated  with 
changing  legacy  business  processes. 

The  term  legacy  business  processes  refers  to  processes  (consisting 
of  people,  systems,  and  organizational  structure)  which  have  been 
institutionalized  within  a  business.  The  use  of  the  term  legacy 
systems  has  been  widely  used  by  both  government  and  commercial 
business  sectors  to  refer  to  institutionalized  hardware/software 
systems. 

Over  time,  businesses  have  established  cultures  and  procedures 
which  have  allowed  the  business  to  survive,  but  as  a  result  have 
become  the  environmental  constraints  which  impede  process 
change.  This  history  (legacy)  is  often  embedded  into  the  minds  and 
attitudes  of  employees,  giving  them  pride  of  ownership  in  the 
existing  business  process.  In  addition,  much  of  the  business 
process  design,  which  is  commonly  well  documented  during  initial 
engineering  stages,  is  frequently  neglected  as  the  business  evolves. 
As  a  result,  the  existing  business  process  design  is  maintained  in 
many  loose  forms  including  memorandums,  meeting  notes, 
procedure  documentation,  and  the  minds  of  employees.  Within  this 
text,  this  loosely  organized  set  of  business  process  materials  is 
referred  to  as  Business  Process  Knowledge. Employees  may  view 
this  loose  form  of  process  information  as  a  source  of  job  security, 
making  them  even  more  reluctant  to  share  and/or  participate  efforts 
advocating  change. 

What  makes  the  BPR  transformation  even  more  complicated  is  the 
demand  for  short-term  results.  Only  an  organization  committed  and 
prepared  to  accept  the  challenge  of  a  rapid  re-evolution  (or 
revolution)  will  receive  the  greatest  gains. 

Throughout  this  document,  an  emphasis  is  placed  on  adding  value. 
Care  must  be  taken  to  ensure  that  the  overall  impact  of 
revolutionary  thinking  and  actions  results  in  a  positive  or  "value 
added"  business  impact. 
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Continuous 

Reengineering 


The  question  of  "Will  we  ever  have  to  reengineer  again!"  is  similar 
to  asking  "Should  we  ever  re-think  our  business  processes!".  When 
to  reengineer  is  dependent  on  how  well  a  process  evolves  over  time 
towards  strategic  goals  established  for  the  business. 


INTEGRATION  OF  BPR  WITH  TOTAL  QUALITY  MANAGEMENT 


The  focus  of  Chapter  5,  entitled  "Transformation  and  Evolution", 
is  to  describe  how  the  results  of  reengineering  are  integrated  within 
the  Total  Quality  Management  (TQM)  culture  of  a  business 
enterprise.  Therefore,  only  a  brief  overview  of  the  BPR-TQM 
interaction  will  be  presented  within  this  chapter. 


What  is  Total  Quality 
Management  (TQM)? 


The  concept  of  TQM  is  so  broad  in  nature  that  all  strategies, 
methodologies,  and  techniques  for  business  improvement 
(including  BPR)  fall  within  its  preview.  But,  without  BPR,  TQM  is 
much  like  chewing  a  steak  without  teeth;  you  may  go  hungry 
before  you  can  swallow.  BPR  adds  the  "quick  strike"  capability 
that  TQM  often  lacks  in  practice. 

In  the  book  entitled  "A  Guide  to  Implementing  Total  Quality 
Management" ,  published  by  the  Reliability  Analysis  Center  in 
1990,  Total  Quality  Management  (TQM)  is  described  in  the 

following  manner. 

...........  .  ..  .  ........  ... 

TQM  consists  of  continuous  process  improvement 
activities  involving  everyone  in  an  organization  -  - 
managers  and  workers  -  -  in  a  totally  integrated  effort 
toward  improving  performance  at  every  level.  This 
improved  performance  is  directed  toward  satisfying 
such  cross-functional  goals  as  quality,  cost,  schedule, 
mission,  need,  and  suitability.  TQM  integrates 
fundamental  management  techniques,  existing 
improvement  efforts,  and  technical  tools  under  a 
disciplined  approach  focused  on  continuous  process 
improvement.  The  activities  are  ultimately  focused  on 
increased  customer/user  satisfaction. 
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Continuous  Process 
Improvement 


TQM  has  long  promoted  the  concept  of  continuous  process 
improvement  or  just  continuous  improvement,  which  includes  an 
organized  set  of  tools  and  techniques  used  to  continually  improve 
processes.  Continuous  improvement  strategies,  as  commonly  used 
to  date,  advocate  " tweaking "  the  existing  process  to  improve 
performance  over  time.  The  continuous  improvement  strategies  of 
TQM  rarely  consider  the  radical  thoughts  that  form  the  foundation 
of  BPR,  such  as  " let's  start  from  scratch".  Where  continuous 
improvement  efforts  generally  lead  to  gradual  process 
improvements,  BPR  efforts  can  lead  to  "breakthroughs"  or  rapid 
process  improvements.  It  should  be  noted  that  the  more  rapid  and 
radical  nature  of  BPR  may  also  increase  the  risk  of  failure  in 
implementation.  As  the  following  figure  illustrates,  the  goal  of 
BPR  is  to  achieve  improvements  of  a  degree  over  standard 
continuous  improvement  applications  within  the  same  period  of 
time.  This  text  recommends  utilizing  BPR  strategies  followed  by 
continuous  improvement  strategies  to  effectively  revolution  and 
evolution. 


Process 

Improvement 


Figure  1.5-1.  Process  Improvement 

In  addition,  those  implementing  TQM  have  often  lacked  a  business 
process  focus,  resulting  in  sub- optimization  of  activities  within 
organizations.  BPR  has  raised  the  view  of  TQM  practitioners  to 
focus  on  business  process  improvement,  not  local  problem 
resolution. 
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Process  Evolution 


BPR  Never  Ends 


As  illustrated  in  Figure  1.2-1,  business  processes  are  in  one  of  the 
four  phases  of  the  Process  Management  Life  Cycle  (PMLC).  A 
process  in  evolution  is  one  which  has  previously  been  engineered 
or  reengineered,  yielding  the  existing  institutionalized  process 
design  (referred  to  as  a  legacy  process). 


Figure  1.5-3.  Relationship  between  BPR  and  Continuous 
Improvement 

Continuous  improvement  represents  the  means  by  which  a  legacy 
process  is  gradually  improved  through  controlled  process 
evolution.  Controlled  process  evolution  represents  a  process  state 
in  which  continuous  process  improvements  are  utilized  to  evolve 
processes  in  a  value-added  manner.  In  addition,  business  process 
goals  and  targets  are  passed  from  the  engineering  and 
reengineering  phases  to  help  give  direction  to  process  evolution 
activities,  thus  limiting  the  need  to  later  reengineer. 

The  intent  of  this  section  is  not  to  recommend  the  replacement  of 
continuous  process  improvement  or  to  present  a  new  term  with  the 
same  meaning  as  continuous  process  improvement,  but  rather  to 
provide  a  better  understanding  of  the  use  of  continuous 
improvement  strategies  within  a  specific  phase  of  the  Process 
Management  Life  Cycle.  To  those  from  the  software  world, 
controlled  process  evolution  may  be  considered  similar  to  placing 
software  under  configuration  control  as  part  of  a  Configuration 
Management  (CM)  plan.  All  changes  to  the  process  are  strictly 
monitored,  documented,  and  controlled. 

BPR  is  a  never  ending  activity.  Each  business  process  is  constantly 
reviewed  by  the  reengineering  team  to: 

•  ensure  proper  business  process  goals  and  targets 

•  identify  high  impact,  "unhealthy"  processes  to  reengineer 
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Refer  to  Chapter  5,  entitled  "Transformation  and  Evolution",  for 
greater  insight  into  Total  Quality  Management  and  Continuous 
Process  Improvement  methodologies  and  approaches. 


1 .6.  Business  process  Reengineering  Building  Blocks 

Effective  BPR  integrates  people,  technology,  and  business 
processes  under  the  guidance  of  strategy  and  methodology.  Those 
who  take  a  critical  view  of  these  building  blocks  should  recognize 
that  people,  technology,  and  business  processes  are  existing 
elements  within  the  business  enterprise,  and  that  BPR  is  truly  the 
mechanism  by  which  strategy  and  methodology  can  effectively 
utilize  and  restructure  these  resources,  adding  value  to  both  process 
and  product.  Therefore,  strategy  and  methodology  have  the 
greatest  overall  impact  on  BPR  implementation  and  tend  to  balance 
how  the  other  business  elements  (people,  enabling  technology,  and 
business  processes)  are  integrated. 

1.6.1.  People 

Even  with  an  increased  emphasis  on  technology  and  automation, 
people  still  represent  the  strongest  contributing  resource  to  BPR. 
The  majority  of  process  and  business  process  knowledge  resides 
with  individuals  who  can  collectively  support  or  derail  a  BPR 
effort.  How  people  interact  with  business  processes  through 
information  technology  and  process  technology  solutions  greatly 
impacts  the  operational  efficiency  of  business  processes.  The  intent 
of  BPR  is  not  to  remove  people  from  the  business  (i.e.  staff 
reductions),  yet  as  a  result  of  BPR  application,  the  number  of 
people  required  to  perform  a  process  may  decrease.  Performing 
processes  more  efficiently  often  means  using  fewer  resources 
(including  people)  to  complete  required  activities.  The  intent  of 
BPR  is  to  drastically  improve  process  performance  over  time  by 
integrating  people  and  technology  as  enablers. 

1.6.2.  BUSINESS  PROCESSES 

All  businesses  have  functioning  business  processes.  Business 
processes  represent  the  engine  by  which  a  business  operates,  with 
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information,  people,  and  materials  being  the  fuels/resources 
necessary  to  keep  the  engine  running.  Hammer  and  Champy  would 
argue  that  the  goal  of  BPR  is  not  to  fix  existing  business  processes, 
but  to  completely  redesign  (change)  a  business  process.  In  short, 
they  recommend  a  complete  engine  overhaul  or  replacement. 
Regardless  of  whether  fixing  or  redesigning  a  business  process  is 
required,  rethinking  of  business  processes  is  a  necessity. 

Information  is  considered  as  part  of  the  business  process  building 
block,  since  information  is  created,  maintained  within,  and  output 
from  processes.  As  described  in  later  sections  of  this  document, 
information  plays  a  vital  role  in  the  transformation  of  a  business 
process  during  reengineering. 


1.6.3.  TECHNOLOGY 

To  remain  competitive,  an  organization  must  constantly  evaluate 
its  machinery,  control  systems,  information  systems, 
communication  resources,  and  procedures.  Each  portion  of  the 
overall  system  must  be  periodically  upgraded  to  incorporate 
efficient  new  technologies  and  methods. 

Most  of  today's  technology  is  obsolete  long  before  it  wears  out.  In 
addition,  many  market  developments  will  result  in  systems  which 
are  obsolete  before  they  are  completed.  An  inadequate  solution 
may  be  proposed  for  a  big  problem,  or  inordinate  amounts  of 
personnel,  time,  and  money  may  be  squandered  on  a  grandiose 
development  scheme.  As  a  result,  completed  systems  and 
associated  processes  often  fail  to  satisfy  customer  needs  and 
expectations. 

There  is  no  such  thing  as  a  perfectly-designed  system  or  process 
that  can  meet  all  possible  customer  needs  over  a  long  period  of 
time  without  change.  Ideally,  a  newly  upgraded  computerized 
system  is  configured  so  that  it  can  be  adapted  to  meet  changing 
requirements  without  wholesale  replacement.  Advance  planning 
and  diligent  up-front  attention  to  the  application  of  appropriate 
technologies  will  help  to  ensure  that  automation  is  properly  aligned 
with  business  process  workflow. 
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Increasingly,  automation  is  becoming  the  cornerstone  of  any 
process  improvement  effort.  The  methodology  outlined  in  this 
document  supports  the  effective  insertion  of  enabling  technologies 
relative  to  a  systems  engineering  and  BPR  context.  In  other  words, 
this  document  supports  not  just  the  automated  system  itself,  but  the 
concomitant  interface  between  man,  machine,  and  process. 

1.6.4.  Strategy  &  Methodology 

Without  strategy  and  methodology,  business  process  improvement 
would  primarily  be  guesswork.  This  document  focuses  on  how  to 
apply  strategy  and  methodology  as  an  integrated  approach  to  BPR. 

1 .7.  Business  Process  Reengineering  Critical  Factors 

Much  like  Total  Quality  Management  (TQM),  the  success  or 
failure  of  BPR  hinges  on  a  few  key  factors.  The  U.S.  General 
Accounting  Office  (GAO)  held  a  symposium  on  BPR  in  December 
1994,  the  results  of  which  were  summarized  into  a  set  of  five  key 
principles  for  successful  reengineering: 

Principle_I:  Top  management  must  be  supportive  of 
and  engaged  in  reengineering  efforts  to  remove 
barriers  and  drive  success. 

Principle  U.  An  organization's  culture  must  be 
receptive  to  reengineering  goals  and  principles. 

Principle  III.  Major  improvements  and  savings  are 
realized  by  focusing  on  the  business  from  a  process 
perspective  rather  than  afunctional  perspective. 

Principle  TV.  Processes  should  be  selected  for 
reengineering  based  on  a  clear  notion  of  customer 
needs ,  anticipated  benefits,  and  potential  for  success. 

Principle  V.  Process  owners  should  manage 
reengineering  projects  with  teams  that  are  cross¬ 
functional,  maintain  a  proper  scope,  focus  on  customer 
metrics,  and  enforce  implementation  timeliness. 
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Those  from  the  world  of  hardware  engineering  may  refer  to  critical 
factors  from  a  slightly  different  perspective,  such  as  critical  failure 
modes.  The  most  recognized  factors  are  not  those  relating  to 
engineering  tools,  information  technology,  or  detailed  process 
modeling  techniques,  but  those  relating  to  preparation  and 
education.  Few  organizations  take  the  time  to  prepare  themselves 
to  properly  rethink  business  processes  or  educate  themselves  to 
consider  such  simple,  yet  critical,  factors  as  the  those  described  in 
the  following  subsections. 

1.7.1.  Managing  threat  of  Change 

Regardless  of  the  detailed  wording  of  definitions  associated  with 
BPR,  phrases  such  as  rethinking  and  radical  redesign  clearly  stand 
out.  The  very  definition  implies  that  the  old  business  environment 
will  likely  be  thrown  away  or  significantly  restructured,  thus 
creating  a  perceived  threat  to  the  existing  systems,  people, 
processes,  and  culture.  Upon  learning  of  the  impending  devastation 
to  be  caused  by  BPR  through  "radical  redesign",  the  workforce 
creates  defensive  barriers  limiting  communication  and  eventually 
stalling  progress.  The  workforce  will  tend  to  defend  against  what 
they  do  not  understand.  Therefore,  creating  a  culture  where  people 
become  enabling  factors  rather  than  barriers  is  critical  to  successful 
BPR. 

1 .7.2.  DEFINITION  OF  BUSINESS  SUCCESS 

Even  though  BPR  is  not  a  science,  it  is  also  not  "witchcraft".  Most 
principles  involve  common  sense  business  management.  The 
fundamental  theory  behind  BPR  involves  setting  strategic  goals 
which  will  yield  a  successful  business,  and  then  aligning  and 
restructuring  business  processes  to  meet  the  desired  goals.  Many 
organizations  make  the  critical  mistake  of  attempting  to  redesign 
processes  without  first  understanding  and  quantifying  strategic 
business  goals  with  respect  to  business  success.  Industry  leaders 
continually  point  to  the  commitment  of  management  to  BPR 
success,  yet  fail  to  describe  what  the  commitment  includes.  As  a 
minimum,  management  must  be  involved  in  establishing  a 
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definition  for  success  and  a  set  strategic  goals  and  targets  which 
will  promote  the  survival  and  growth  of  the  business. 

1.7.3.  UNDERSTANDING  BUSINESS  VALUE 

Many  businesses  that  have  survived  the  test  of  time  have  also 
struggled  through  evolution.  Business  evolution  has  caused  the 
business  to  adapt  to  changing  business  environments,  customer 
needs,  and  internal  problems  in  order  to  maintain  a  solvent 
business  enterprise.  As  a  result,  inefficient  and/or  obsolete 
processes  have  evolved  and  have  not  been  removed,  repaired,  or 
totally  redesigned.  Much  like  a  world-class  athlete  who  must 
understand  and  engineer  his  or  her  body  in  order  to  achieve 
maximum  performance  without  wasting  valuable  energy  and  time, 
a  business  enterprise  must  ensure  that  resources  and  process 
designs  are  effectively  aligned  to  promote  immediate  increases  in 
business  value. 

1.7.4.  DEFINITION  OF  A  BUSINESS  PROCESS 

The  fundamental  building  block  of  BPR  is  the  business  process. 
Organizations  often  tell  stories  of  well  intentioned  BPR  teams 
(many  times  led  by  professional  consultants)  that  have  expended 
months  of  effort  without  a  clear  definition  of  business  processes. 
The  BPR  industry  as  a  whole  has  struggled  to  establish  a  definition 
of  a  business  process  which  is  simple,  comprehensive,  and 
repeatable. 

Section  3.1  of  this  text  provides  a  clear  definition  of  a  business 
process. 

1.7.5.  Understanding  The  Big  picture 

The  size,  complexity,  and  organizational  structure  of  a  business 
have  a  significant  impact  on  the  amount  of  bends,  curves,  and 
speed-bumps  in  the  road  to  transformation  of  a  business  process. 

In  general,  the  larger  the  organization  and  greater  the  depth  of  the 
business  hierarchy  (number  of  layers),  the  greater  the  amount  of 
culture  and  infrastructure  change  required.  Conversely,  the  smaller 
and  flatter  the  business  is,  the  less  resistance  there  is  to  change. 
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Those  seeking  to  succeed  in  reengineering  must  clearly  understand 
the  magnitude  of  the  business  enterprise,  as  well  as  the  level  of 
control  required  to  change  the  business  or  related  organization. 
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Where  Am  I? 


Think  Before  You  Act 


In  this  chapter,  the  seeds  are  planted  for  transformation  of  the 
business  enterprise.  While  existing  plans,  information,  and 
strategies  will  still  be  of  use,  it  is  important  that  these  resources  be 
organized  in  a  structured  manner  to  establish  a  strong  foundation 
for  Business  Process  Reengineering.  It  may  also  be  necessary  to 
consider  the  organization  as  a  clean  slate,  waiting  for  invention 
and  innovation  to  create  an  exciting,  new,  thriving  enterprise. 

As  illustrated  in  Figure  2-1,  the  Preparation  step  will  yield  a  clear 
definition  of  the  business  mission,  goals  and  targets,  and  initiate 
organization  and  education  within  the  enterprise. 


Reengineering 


YOU 

ARE 
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Preparation 

Identification  __ 
&  Assessment 

»> 

Innovation  &  _ 
Redesign 

Transformation 

— « - w? 

■  ;  ■  ,  , 

Process  Management  Notebook 

Chapter  2, 

Business  Mission  Statement 
Business  Goals/Targets 
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Figure  2-1.  Overview  of  Preparation 


Reengineering 


Engineering 


Retirement 


Evolution 


The  Software  Reengineering  Assessment  Handbook  (SRAH) 
prepared  by  the  Air  Force  Software  Technology  Support  Center 
(STSC)  describes  preparation  as  the  most  important  step  in 
software  reengineering.  Preparation  is  equally  as  important  to 
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The  Impact  of 
Reengineering 


reengineering  of  a  business  enterprise,  since  it  results  in  a  strong 
foundation. 

Initiators  of  BPR  projects  have  often  made  an  intuitive  leap  from 
the  identification  of  symptoms  or  opportunities  to  concrete 
development  action  plans.  The  complexity  of  understanding 
interactions  between  cooperating  workers,  interconnected 
machines,  or  operators  and  processes  makes  it  easier  to  accept  a 
generalized,  potentially  expensive  course  of  action  like: 

•  "Automate  it." 

•  "Reorganize  and  Restructure" 

•  "Reduce  Staff 

•  "Contract  it  out." 

•  "Bring  it  in-house." 

•  "Replace  the  whole  system." 

As  a  minimum,  this  "leap"  requires  sound  understanding  and 
preparation  prior  to  selection  and  implementation  of  a  business 
process  solution. 

New  business  processes  will  replace  existing  processes,  integrate 
functions  formerly  performed  by  separate  systems  and  procedures, 
implement  entirely  new  functions,  or  any  combination  of  the 
above.  An  existing  process  may  encompass  manual  procedures, 
paper  forms,  file  cabinets,  computers,  entry  and  report  programs, 
electronic  data  storage  structures  and  mechanisms,  data 
communication  facilities,  etc.  Upsetting  the  status  quo,  even  with 
a  process  which  works  well,  is  always  disruptive  to  operations  and 
personnel.  Therefore,  BPR  must  not  be  undertaken  without  a  clear 
understanding  of  the  need  for  and  scope  of  the  proposed  effort. 

Much  like  world-class  athletes  must  prepare  themselves  both 
mentally  and  physically  in  order  to  successfully  compete,  business 
organizations  must  do  the  same.  Effective  preparation  involves: 

•  getting  management  commitment 

•  establishing  a  business-level  reengineering  team 
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•  establishing  an  equation  for  business  success 

2.1.  Get  Management  Commitment 

There  have  been  many  articles,  books,  and  speeches  about  the  need 
to  get  commitment  from  management  prior  to  attempting  a 
reengineering  effort.  Most  managers  would  emphatically  say  "we 
are  committed!"  and  wonder  why  anyone  would  think  that  they 
aren't.  This  gap  in  understanding  is  due  to  the  fact  that  rarely  is 
management  shown  "what  commitment  is  required"  or  "how  to  get 
involved". 

While  the  information  presented  within  the  rest  of  this  chapter  is 
useful  for  both  management  and  technical  staff,  the  primary  results 
from  the  Preparation  step  are  the  responsibility  of  management 
and,  therefore,  represent  the  first  step  in  management  commitment 
to  the  reengineering  of  business  processes. 

Many  analysts  claim  that  the  primary  commitment  of  management 
should  be  monetary.  This  text  focuses  on  the  commitment  of 
management  through  time  and  thought  which  may  later  lead  to  the 
commitment  of  dollars,  but  only  if  efforts  show  a  positive  Return- 
On-Investment  (ROI).  Management  has  no  problem  investing 
dollars  if  the  result  will  have  a  demonstrated  positive  effect  on 
their  bottom  line. 

2.2.  Establish  A  Business-Level  Reengineering  Team 

During  this  initial  step,  it  is  critical  that  all  efforts  are  focused  on 
the  business  enterprise.  A  business-level  reengineering  team, 
referred  to  as  an  Enterprise  Reengineering  Team  (ERT)  in  this 
document,  will  set  direction  for  process  change,  support  process 
transformation  with  necessary  resources,  and  ensure  new  process 
designs  align  with  business  goals/targets.  Therefore,  the  team 
attributes  outlined  within  this  section  are  meant  to  relate  directly  to 
the  business  enterprise. 

Once  a  process  or  processes  are  selected  for  reengineering  (as 
described  in  the  next  chapter),  a  process-level  reengineering  team 
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2.2.1.  Team  Attributes 


Individual 

Characteristics 


or  Process  Action  Team  (PAT)  will  be  established  with  similar 
characteristics,  but  focused  on  a  single  process. 


Enterprise 
Reengineering  Team 


_ 1 1 _ 1  Process 

1  /Process 

im 

Process 

im 

Action  Team 

Figure  2.2-1.  Reengineering  Team  Structure 

This  text  recommends  the  use  of  Process  Action  Teams  to  support 
evolution,  as  well  as  reengineering,  of  processes.  Therefore,  PATs 
should  be  established  for  each  business  process  regardless  of 
whether  a  process  requires  immediate  reengineering. 

Chapter  5  entitled  "Transformation  and  Evolution"  provides 
further  information  on  the  role  of  PATs  in  process  improvement. 


Preparation  is  as  much  a  mental  exercise  as  a  physical  exercise. 
Collectively,  the  Enterprise  Reengineering  Team  (ERT)  represents 
the  business  " mind ",  encompassing  the  key  managers,  directors, 
and  thinkers  within  a  business  enterprise.  Generally,  the  mind 
makes  intelligent  decisions  and  directs  appropriate  actions  when 
provided  sound  information.  A  common  complaint  of  managers 
and  executives  is  that  they  are  forced  (or  choose)  to  make  business 
decisions  without  thoroughly  understanding  the  problem  (i.e.,  lack 
of  accurate  and  timely  information). 

Therefore,  the  business  mind  must  include  individuals  who  are 
responsible  for  the  "senses"  of  the  business  enterprise.  In  the  book 
entitled  "Successful  Reengineering"  by  Petrozzo  and  Stepper, 
attributes  of  reengineering  team  members  and  facilitators  are 
described,  including: 
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•  management  level 

•  big  picture,  systems  thinking 

•  technically  complete 

•  self  motivated,  committed 

•  good  interpersonal  skills 

•  team  oriented 

•  creative 

•  respected 

While  it  would  be  difficult  to  find  such  a  diverse  individual,  a 
collective  group  of  individuals  may  comprise  such  characteristics. 
In  order  to  ensure  that  the  business-level  reengineering  team  is 
well  informed,  the  team  may  charter  individuals  or  groups  to  study 
and  gather  critical  business  information  to  support  team  decisions. 

Champion  Many  experts  also  point  to  the  need  for  a  " champion "  to  act  as  the 

primary  driver  of  the  reengineering  effort  and  commonly  perform 
as  the  reengineering  team  leader.  From  a  business  perspective,  this 
person  should  be  a  business  executive,  serving  to  ensure  the 
management  commitment  described  in  the  previous  section. 

Public  Relations  por  large  organizations,  experts  recommend  the  addition  of  a 

public  relations  representative  to  the  reengineering  team. 
Regardless  of  the  business  size,  individuals  throughout  the 
enterprise  must  be  informed  of  the  need  for  reengineering,  and 
educated  to  reduce  misconceptions  relating  to  the  threat  of  change. 

2.2.2.  TEAM  IMPLEMENTATION  ENVIRONMENT 

A  key  concern  when  establishing  an  innovative  business 
environment  is  that  of  education.  Team  members  must  understand 
the  purpose  and  direction  of  business  activities  in  order  to  truly 
commit  to  achieving  positive  results.  A  team  environment  often 
depends  on  a  change  in  culture.  Since  the  perceptions  of 
individuals  left  over  from  years  of  experience  must  be 
systematically  redirected,  culture  changes  are  not  achieved 
instantly.  Dr.  W.  Edwards  Deming's  philosophy  to  creating  such  a 
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Top  Down  -  Bottom  Up 
Implementation 


management  culture  resulted  in  the  Fourteen  Points  for 
Management  listed  in  the  following  figure. 

1.  Create  constancy  of  purpose  for  improvement  of  product 
and  service 

2.  Adopt  the  new  philosophy 

3.  Cease  dependence  on  inspection  to  achieve  quality 

4.  End  the  practice  of  awarding  business  on  the  basis  of 
price  tag  alone 

5.  Improve  constantly  and  forever  the  system  of  production 
and  service 

6.  Institute  training 

7.  Adopt  and  institute  leadership 

8.  Drive  out  fear 

9.  Breakdown  barriers  between  staff  areas 

10.  Eliminate  slogans,  exhortations,  and  targets  for  the  work 
force 

1 1 .  Eliminate  numerical  quotas  for  the  work  force  and 
eliminate  goals  for  people  in  management 

12.  Remove  barriers  that  rob  people  of  pride  of  workmanship 

13.  Encourage  education  and  self-improvement  for  everyone 

14.  Take  action  to  accomplish  the  transformation _ 

Figure  2.2-2.  Deming's  Fourteen  Points  for  Management 

Successful  reengineering  requires  that  enterprise  level  teams 
communicate  the  business  mission,  goals,  and  targets  to  operations 
level  teams  (commonly  consisting  of  Process  Action  Teams).  In 
return,  PATs  will  redesign  business  processes  to  achieve  desired 
goals,  improve  process  workflow,  and  provide  continuous 
feedback  to  enterprise  level  teams.  This  integrated  team 
environment  (illustrated  in  Figure  2.2-3)  must  be  emphasized 
throughout  all  stages  of  reengineering. 
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Enterprise  Level 


Business  Level 


Operations  Level 


Figure  2.2-3.  Top  Down  -  Bottom  Up  Team  Implementation 


Record  Enterprise 
Reengineering  Team 
Description 


CSK  Example:  Team 
Structure 


Once  the  ERT  is  constructed,  a  brief  mission  statement  or  charter 
should  be  recorded  for  the  team.  The  ERT  description  should 
include  identification  of  team  members,  roles  and  responsibilities 
of  each,  team  goals,  and  an  overview  of  the  environment  in  which 
meetings  should  be  held.  Recording  the  ERT  description  in  the 
Process  Management  Notebook  will  provide  team  members  and  all 
staff  with  a  clear  understanding  of  the  ERT  scope  and  objectives. 

CSK  started  reengineering  efforts  by  constructing  a  small 
enterprise  reengineering  team  consisting  of  the  company  president, 
the  manager  of  information  systems,  and  an  independent  BPR 
consultant.  The  CSK  ERT  established  the  initial  CSK  business 
goals,  evaluated  business  processes,  selected  processes  for 
reengineering  by  looking  for  potential  breakthroughs,  and 
established  flexible  teams  (PATs)  to  attack  specific  process 
reengineering  efforts. 


2.3.  ESTABLISH  AN  EQUATION  FOR  BUSINESS  SUCCESS 

Previous  paragraphs  discussed  the  high  failure  rate  of  BPR 
projects,  yet  there  has  been  no  previous  mention  of  how  "success" 
is  defined.  It  is  not  the  intent  of  this  section  to  discuss  success  in 
theoretical  terms,  but  rather  to  draw  a  correlation  between  success 
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and  the  transformation  of  a  business  process.  This  section  will  first 
define  an  equation  for  success  from  the  highest  level  in  a 
conceptual  form  and  then  decompose  the  results  into  more  concrete 
components. 


2.3.1.  SURVIVAL 


First,  consider  the  following  statement: 

An  organization  must  survive  in  order  to  succeed. " 


The  current  business  environment  leaves  organizations  struggling 
to  survive.  Survival  is  based  on  performing  mission  essential 
activities  well  enough  to  maintain  current  business  effectiveness. 
Since  competitors  are  rapidly  improving  their  quality  of  services 
and  reducing  costs,  survival  represents  a  challenge  to  "Keep  up 
with  the  Jones'"  or  at  least  maintain  a  State-of-the-Practice. 

Therefore,  the  initial  equation  yields: 

Success  =  Survival 

If  the  business  goal  is  only  to  survive,  then  most  likely  the  equation 
is  complete,  and  the  organization  will  not  reach  beyond  the  goal 
itself  leaving,  at  best,  survival. 

2.3.2.  Growth/Excellence 

Based  on  the  premise  that  many  businesses  may  be  unwilling  to 
accept  survival  as  their  definition  of  success,  the  equation  must  be 
adapted  to  allow  for  "growth"  or  achieving  excellence. 

Figure  2.3-1  illustrates  the  view  of  a  business  enterprise  as  a  three- 
dimensional  box.  For  example  purposes,  the  dimensions  of  the  box 
have  been  assigned  labels  such  as  Profit,  Diversity,  and  Stability. 
Each  business  enterprise  must  determine  what  factors  have  the 
greatest  impact  on  success  over  time  by  asking  the  question  "What 
measurements,  when  taken  together,  most  accurately  indicate 
business  success?" 
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Profit 

($$  In  -  $$  Out) 


( Types  of  Customers  &  Products ) 


Figure  2.3-1.  Business  Enterprise  Box 


A  business  which  only  survives  may  change  in  dimension,  but 
overall,  will  consume  the  same  area.  A  business  which  chooses  to 
grow,  must  be  able  to  change  the  dimensions  while  consuming  a 
greater  business  enterprise  area  over  time. 

As  a  result  of  this  assumption,  the  equation  for  success  is  adapted 
to  yield: 

Success  =  Survival  +  Growth 

The  simple  nature  of  the  equation  is  vital.  Note  that  only 
reengineering  efforts  which  have  a  "value-added"  impact  on 
business  survival  or  growth  (excellence)  can  truly  be  successful. 

2.3.3.  Setting  Business  Goals  &  Targets 

Prior  to  a  discussion  of  business  goals,  it  is  important  to  recognize 
the  difference  between  "business  goals/targets"  and  "process 
goals/targets" .  Business  goals  represent  goals  established  at  the 
business  enterprise  level  which  directly  impact  business  success, 
while  process  goals  are  goals  related  to  a  single  process  and  may 
not,  by  themselves,  directly  impact  business  success.  Organizations 
which  strive  to  meet  process  goals  without  fully  understanding  the 
impact  of  the  process  on  the  overall  business  goal  will  often  meet 
with  disaster.  Together,  the  business  goals  established  should 
represent  a  path  to  business  success.  Therefore,  each  business  goal 
represents  a  breakdown  of  the  business  success  equation. 
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Figure  2.3-2.  Business  Success  Decomposition 

Most  businesses  breakdown  success  into  more  than  one  and  less 
than  ten  business  goals. 

Recent  surveys,  such  as  the  Corporate  Reengineering  Survey 
(Gateway,  1993-1994),  have  identified  goals  important  to 
businesses,  including  those  shown  in  Figure  2.3-3. 

Most  A 

Important  Increase  Profitability 

Increase  Customer  Satisfaction 
Decrease  Costs 
Increase  Revenue 
Increase  Quality 
Improve  Market  Share 
Increase  Accuracy 
Least  Increase  Speed 

Important  * 


Figure  2.3-3.  Example  Ranked  Organization  Goals 

As  shown  in  Figure  2.3-3,  goals  are  often  phrase  oriented,  such  as 
" Increase  Profitability"  indicating  the  dimension  (Profitability)  of 
the  business  which  will  change  and  the  direction  (Increase)  of  the 
change  required.  Most  goals  do  not  provide  further  insight  into  the 
degree  of  change  required  to  meet  a  goal  or  the  relationship 
between  goals  in  meeting  success.  For  example,  if  a  critical 
dimension  of  the  business  is  profit,  then  a  common  goal  would  be 
to  increase  profit.  Will  the  business  be  successful  as  long  as  there 
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Establish  Targets  as  a 
Window  of  Success 


is  the  slightest  profit  increase?  This  document  separates  business 
goals  (phrases  which  indicate  both  the  dimension  and  direction  of 
business  change)  and  business  targets  (specific  range  of  goals 
which  indicate  degree  of  business  change  required). 


Most  BPR  professionals  would  agree  with  the  concept  of 
establishing  both  "realistic  targets"  (those  targets  which  are  clearly 
obtainable  to  all  involved)  and  "stretch  targets"  (those  targets  that 
represent  a  significant  breakthrough  for  the  business  enterprise).  If 
defined  correctly,  such  business  targets  may  represent  the  upper 
and  lower  bounds  for  business  success.  In  other  words,  such 
business  targets  may  be  used  as  a  measuring  stick  to  effectively 
determine  the  level  of  business  success  (including  survival  or 
growth)  or  failure. 


An  example  of  both  realistic  and  stretch  business  targets  may  be  to 
"reduce  operating  expenses  by  a  minimum  of  10%  and  a  stretch 
target  of  20%  over  the  next  12  months".  These  targets  may  have  a 
direct  impact  on  business  success  by  affecting  profit,  assuming  that 
income  remains  constant.  Each  target  must  be  directly  related  to  a 
critical  business  goal,  as  illustrated  in  the  following  diagram. 


Figure  2.3-4.  Correlation  of  Targets  to  Business  Goals 
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Record  Business  Goals  & 
Targets 


Walking  the  Line 
Between  Success  and 
Failure 


2.3.4.  BENCHMARKING 


Later  in  this  document  the  concept  of  determining  whether 
processes  add  value  will  be  discussed.  As  a  minimum,  activities 
which  add  value  must  directly  affect  business  goals/targets  and 
therefore  directly  affect  business  success. 

Since  business  goals  and  targets  represent  the  yardstick  by  which 
success  of  a  reengineering  effort  will  be  measured,  such  goals  and 
targets  should  be  recorded  in  the  Process  Management  Notebook. 
Later  in  the  reengineering  effort,  new  process  designs  will  be 
evaluated  against  the  initial  goals  to  ensure  process  changes 
translate  to  the  desired  business  improvements. 

The  concept  of  a  business  enterprise  box  may  also  be  helpful  to 
understand  and  illustrate  failure.  Few  organizations  can  withstand  a 
negative  profit  margin  for  a  prolonged  period  of  time.  Failure  to 
meet  goals  will  eventually  turn  the  business  enterprise  box  into  a 
business  enterprise  pit.  A  simple  line  chart  may  be  used  to  monitor 
the  progress  and  impact  of  reengineering  efforts  on  business 
indicators  such  as  the  chart  illustrated  in  Figure  2.3-5. 


Business 

Indicator 

(Profit) 


Figure  2.3-5.  Failure  to  Survive 

A  variety  of  tools  and  techniques  for  monitoring  process  progress 
are  outlined  in  Chapter  5. 


Benchmarking  may  also  be  useful  in  the  determination  of 
appropriate  goals  and  targets  for  business  success.  Knowing  the 
performance  measures  for  processes  of  successful  companies, 
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especially  competitors,  is  extremely  critical  in  measuring-up  to  the 
competition  in  terms  of  both  product  and  process  value. 

A  more  thorough  explanation  of  benchmarking  as  a  means  by 
which  a  business  process  may  be  evaluated  is  provided  in  Chapter 
4,  entitled  "Innovation  and  Redesign" . 


2.3.5.  Managing  Success 

Many  organizations  are  successful  over  short  periods  of  time,  only 
to  fall  victim  to  failure  in  the  long  run.  A  quick  look  at  the  business 
enterprise  box  would  indicate  that  an  organization  could  increase 
profits  during  the  near  future  through  increases  in  operational 
efficiencies  resulting  from  limiting  the  types  of  work  they  perform 
(potentially  reducing  diversity)  and  focusing  on  a  few  customers 
(potentially  reducing  stability).  The  fact  is  that  each  of  the 
dimensions  used  as  an  example  are  significantly  affected  by  the 
customer.  The  statement  that  the  "customer  is  king"  has  never  been 
more  true  than  it  is  today.  Customers  are  more  educated  and  have 
greater  access  to  information  than  ever  before,  making  them  more 
aware  of  what  the  market  place  has  to  offer  and  whether  product 
claims  are  accurate.  Understanding  these  critical  business 
dimensions  is  still  not  enough  to  guarantee  success.  Business 
leaders  must  find  ways  to  control  and  adapt  them. 

Adapting  to  a  Changing  Business  is  conducted  in  an  environment  of  constant  change. 

Environment  „  ,  ,  , 

Customer  needs  and  preferences,  the  strength  and  number  of 

competitors,  product  and  process  technology,  government  policies 

and  regulations,  and  world  market  opportunities  are  all  in  a 

constant  state  of  flux.  To  survive,  a  business  organization  must 

make  the  best  possible  use  of  its  resources.  To  prosper  in  the 

longer  term,  the  organization  must  be  able  to  anticipate,  adapt  to, 

and  take  advantage  of  changing  conditions. 

Planning  Ahead  Strategic  planning  involves  the  systematic  study  of  the  conduct  of 

the  business  and  the  generation  of  appropriate  action  plans  for 
improving  its  competitive  position.  Often,  strategic  planning  is 
constrained  by  the  diverse  pressures  of  business,  such  as  existing 
financial  health  or  human  relations.  In  reality,  a  focus  on  BPR 
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Strategic  Planning  is 
More  than  an  Ivory 
Tower  Exercise 


2.3.6.  DEFINING  BUSINESS 


integrates  strategic  planning  and  the  implementation  of  resulting 
business  improvement  actions  without  initial  bounds  and 
constraints. 

Managers  agree  that  long-range,  comprehensive  goal-setting  is 
necessary.  Too  often,  however,  strategic  planning  is  ineffective 
because  agreed-upon  goals  are  not  methodically  translated  into  a 
set  of  practical  actions.  Sometimes  the  opposite  occurs,  and 
practical  actions  such  as  reengineering  efforts  are  squandered 
because  they  are  not  appropriately  aligned  with  business  goals. 

If  performed  properly  and  used  effectively,  strategic  planning  is 
not  just  an  "ivory  tower"  exercise  performed  by  management  to 
produce  long-range  plans.  Strategic  planning  techniques  have  been 
found  to  be  useful  in  any  situation  where  issues  are  large  and 
complex,  where  a  breakthrough  from  traditional  approaches  is 
needed,  and  where  commitment  and  input  from  many  people  must 
be  sought. 

Strategic  thinking  is  inherently  non-linear,  but  is  not  dependent  on 
intuition.  Techniques  mix  creativity  with  logical  thinking  to  bring 
about  imaginative  recombination  of  the  various  factors  impacting 
future  success.  Events,  trends,  issues,  and  problems  are  broken 
into  constituent  parts,  then  reassembled  in  a  way  which  maximizes 
understanding  of  root  cause  issues  and  eventually  leads  to  effective 
business  goals/targets. 

MISSION/VISION 

There  are  two  types  of  vision  discussed  within  this  text,  a  business 
vision  and  a  process  vision.  A  business  vision  is  discussed  in  the 
form  of  a  business  mission  statement  within  the  following 
paragraphs. 

Process  visions  are  discussed  in  Chapter  4,  as  part  of  " Innovation 
and  Redesign" . 

Burt  Nanus,  in  his  book  "Visionary  Leadership" ,  refers  to  vision  in 
the  following  manner. 
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Record  Business 
Mission  Statement 


Business  Mission 
Statement 


"There  is  no  more  powerful  engine  driving  an 
organization  toward  excellence  and  long-range  success 
than  an  attractive,  worthwhile,  and  achievable  vision  of 
the  future,  widely  shared. 

Many  successful  organizations  are  dedicated  to  the  use  of  a 
Mission  Statement  as  a  formal  method  of  documenting  business 
objectives.  The  new  "generation"  of  mission  statements  are  not 
glossy,  slogan-driven  sentences.  Now  industry  leaders  work 
towards  a  business  mission  statement  that  will  clearly  describe 
what  the  purpose  of  the  business  is  and  how  the  business  intends  to 
fulfill  this  purpose.  If  written  effectively,  the  mission  statement  can 
be  used  to  document  success,  business  dimension  goals,  and 
associated  high-level  approaches. 

To  ensure  that  this  information  is  effectively  captured,  a  "Process 
Management  Notebook "  should  be  initiated,  with  Section  1 
containing  the  business  mission  statement.  An  example  of  the 
general  construction  of  a  mission  statement  follows,  with  bold 
phrases  indicating  areas  for  insertion  of  specific  business 
information: 

The  purpose  of  our  business  is  to  BUSINESS 
PURPOSE.  Our  goals  are  to  ESTABLISH  B  USINESS 
DIMENSION  X  and  to  ESTABLISH  B  USIJNESS 
DIMENSION  Y.  To  meet  these  goals,  we  will 
IMPLEMENT  APPROACH  OVERTIME. 

Typical  mission  statements  range  from  a  few  sentences  to  a  single 
page.  Management  must  take  care  to  ensure  that  each  sentence 
provides  a  clear  message  to  readers. 

Before  further  decomposing  this  concept,  a  recent  example  may  be 
helpful.  In  early  1994,  CSK  Technical,  Inc.  from  Tonawanda,  New 
York  initiated  a  BPR  effort  in  order  to  meet  key  business  goals 
expressed  as  part  of  the  business  mission  statement.  An  example  of 
mission  statement  goals  listed  by  CSK  is  provided  in  the  Figure 
2.3-6. 
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Figure  2.3-6.  CSK  Example  -  Mission  Statement 


CSK  further  characterized  several  of  the  goals  into  targets  for 
survival  and  excellence.  The  targets  established  for  increasing 
gross  revenues  and  controlling  personnel  increases  are  provided  in 
Figure  2.3-7.  The  basic  target  for  excellence  established  by  CSK 
was  to  reach  a  gross  revenue  of  $600,000  per  employee  over  a  five 
year  period.  A  baseline  was  set  at  1993  with  a  gross  revenue  of 
$100,000  per  employee  prior  to  reengineering  activities. 


Figure  2.3-7.  CSK  Example  .'Gross  Revenue  Targets 
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First  Year  In  Review 


CSK  set  a  target  for  gross  revenue  increases  of  approximately  10% 
per  year  per  person  for  survival,  while  a  target  for  excellence  was 
set  at  a  staggering  43%  increase  per  year  per  person. 

While  the  battle  to  remain  successful  is  never  over,  CSK  has  used 
BPR  to  improve  operational  efficiency  and  gain  competitive  edge 
for  at  least  the  near  future.  For  example,  first  year  results 
demonstrated  that  CSK  achieved  a  100%  increase  in  gross  volume 
in  1994  with  a  staff  increase  of  only  25%.  In  addition,  they 
surpassed  their  original  target  for  excellence  as  shown  in  the 
Figure  2.3-8.  Further  information  describing  how  CSK  achieved 
such  dramatic  results  will  be  provided  throughout  the  remainder  of 
this  document. 


□  Excellence 
H  Actual 

1993  1994 


$  Gross 
Revenue  Per 
Employee 


200000 -/| 
150000- 
100000- 
50000- 


Figure  2.3-8.  CSK  Example  :1994  Gross  Revenue  Achievement 
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Where  Am  I? 


Anatomy  of  a  Business 
Process 


At  this  point  of  BPR,  those  involved  have  a  clear  picture  of  how 
the  success  of  BPR  efforts  will  be  judged  with  respect  to  the 
business  enterprise.  With  this  critical  information  as  input,  the  next 
step  is  to  Identify  and  Assess  which  processes  are  candidates  for 
reengineering. 


Transformation 


Innovation  & 
Redesign 


YOU 

ARE 

HERE 


Prnrpsc  \1 


nt  Nntflhnnk 


Chapter  2. 

Business  Mission  Statement 
Business  Goals/Targets 
Organization  &  Education 
Chapter  3. 

Business  Process  Description 
Business  Process  Impact 
Business  Process  Health 


Identification 
&  Assessment 


Preparation 


Reengineering 


Engineering 


Retirement 


Evolution 


Figure  3-1.  Overview  of  Identification  &  Assessment 

A  successful  business  enterprise  can  be  compared  to  a  healthy 
human  body.  Each  body  part  and  organ  work  together  to  perform 
processes  for  successful  body  operation.  To  improve  performance 
of  the  body  to  meet  desired  objectives,  body  processes  must  be 
understood,  quickly  evaluated,  and  potentially  targeted  for  more 
thorough  examination. 
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Consider  the  following  similarities: 

•  Body  parts  and  organs  work  to  maximum  efficiency  if  they 
work  with  each  other.  If  a  single  organ  fails  to  produce  the 
necessary  materials  for  healthy  body  function,  the  entire 
body  will  often  fail  or  require  that  the  necessary  material  be 
supplied  via  external  sources.  In  the  case  of  diabetics,  the 
pancreas  no  longer  produces  sufficient  amounts  of  the 
insulin  necessary  for  body  operation  and  insulin  must  be 
introduced  into  the  body  from  an  external  source. 

•  If  blood  fails  to  reach  a  body  part  for  a  prolonged  period  of 
time,  the  body  parts  affected  will  eventually  fail,  no  longer 
be  of  value  to  the  body  as  a  whole,  and  will  potentially  lead 
to  complete  failure  of  the  body. 

These  are  simple,  yet  common  examples  which  may  also  be 
applied  to  a  business  enterprise.  Business  leaders  often  fail  to 
recognize  the  simple  anatomy  of  their  business  and  the  need  for 
balance  between  processes  within  the  business  enterprise. 

Chapter  Overview  This  chapter  focuses  on  the  examination  of  a  business  in  order  to: 

•  clearly  identify  and  define  business  processes 

•  determine  how  each  process  impacts  successful  business 
operation,  and  whether  the  process  should  be  classified  as 
"unhealthy" 

•  select  processes  for  more  detailed  examination  and 
transformation  which  have  the  greatest  business  impact  and 
currently  are  considered  unhealthy 

3.1.  DEFINE  BUSINESS  PROCESSES 

Within  this  section,  guidelines  are  provided  for  understanding, 
identifying,  and  describing  business  processes.  The  results  of  this 
section  will  form  the  basis  for  a  high-level  business  process  model, 
sometimes  referred  to  as  an  enterprise  model. 
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Details  relating  to  the  existing  process  design  are  not  required 
during  this  step,  but  are  discussed  in  sections  relating  to  process 
analysis  within  Chapter  4. 


3.1.1.  Understanding  Business  Processes 


Numerous  publications  provide  valuable  insight  into  concepts  and 
approaches  to  BPR,  while  few  provide  a  concise  definition  of  a 
business  process.  According  to  Webster's  dictionary,  the  term 
process  is  defined  as: 

...  a  series  of  actions,  changes  or  functions  that 
achieves  an  end  result. " 

A  more  descriptive  definition  is  provided  in  the  Business  Process 
Reengineering  Handbook  written  by  Manganelli  and  Klein  : 

....  an  interrelated  series  of  activities  that  convert 
business  inputs  into  business  outputs 


The  following  figure  clearly  illustrates  the  definition  of  a  business 
process. 


Business  not 
Organization 


Figure  3.1-1.  Business  Process  Overview 

The  most  important  distinction  to  make  when  discussing  processes 
is  in  the  use  of  the  term  "Business".  If  a  "Business  Process"  is 
desired,  then  processes  within  organizations,  divisions,  functional 
areas,  etc.  (referred  to  as  activities  within  this  document)  become 
invisible,  or  become  subsets  of  the  overall  business  process. 
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Internal  process  activities  are  often  separated  by  organizational 
dividing  lines.  Figure  3.1-2  illustrates  how  activities  for  a  single 
process  could  potentially  be  distributed  across  organizational 
boundaries. 


Process 

Boundaries 


Figure  3.1-2.  Physical  Boundaries  of  Process 


Later  sections  of  this  document  discuss  creating  more  detailed 
models  of  the  existing  "as-is"  process  design  and/or  the  new  "to- 
be"  process  designs. 

3.1.2.  IDENTIFY  BUSINESS  PROCESSES 

A  fundamental  set  of  characteristics  relating  to  a  business  process 
includes  the  following: 

•  Starts  with  an  input  to  the  business  enterprise 

•  Includes  all  activities  (subprocesses,  functions,  tasks,  and 
actions)  from  input  to  output  inside  the  business  enterprise 

•  Stops  upon  exit  (output)  from  the  business  enterprise 

Such  characteristics  will  help  validate  a  process  once  identified, 
but  do  not  provide  enough  guidance  to  identify  and  sketch  the 
business  processes  themselves. 

Sketching  Business  A  relatively  simple  approach  to  business  process  identification  is 

Processes 

referred  to  in  this  document  as  input/output  or  "I/O  Matching" 
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List  Inputs  and  Outputs 


Matching  Inputs  and 
Outputs 


matching.  This  technique  can  be  used  in  a  team  environment  to 
quickly  identify  business  processes. 

The  first  step  in  I/O  Matching  is  to  establish  a  list  of  business 
inputs  and  outputs.  It  is  important  to  remember  that  only  inputs  and 
outputs  to  the  business  are  listed,  not  those  between  organizations. 
The  resulting  list  need  not  be  exhaustive,  since  the  objective  at  this 
stage  is  only  to  sketch  the  processes.  As  inputs  and  outputs  are 
matched  as  described  in  the  following  paragraph,  additional  inputs 
and  outputs  will  often  be  identified.  Be  careful  not  to  identify 
inputs/outputs  which  are  subsets  of  previous  list  items.  For 
example,  a  customer  order  covers  all  types  of  orders  and,  therefore, 
the  specific  orders  need  not  be  listed  at  this  time.  The  following 
figure  provides  a  simplified  example  of  input  and  output  lists  for  a 
business  enterprise. 


Inputs 

Outputs 

Customer  Order 

Requested  Customer  Product 

Customer  Inquiry 

Request  for  Supplier  Quotes 

Requested  Supplies 

Response  to  Customer  Inquiry 

Supplier  Bids 

Supplier  Delivery  Order 

Figure  3.1-3.  Example  of  Input/Output  Lists 


Once  a  preliminary  list  of  inputs  and  outputs  is  completed,  the 
objective  becomes  correlation  of  the  lists.  On  the  surface,  this  may 
seem  like  a  first  grade  exercise,  yet  it  represents  the  most 
fundamental  of  process  identification  techniques.  It  may  be  helpful 
to  view  this  approach  in  terms  of  a  business  "stimulus"  and 
"response(s)".  Each  input  (stimulus)  will  result  in  one  output 
(response)  or  many  outputs  (responses).  In  the  following  figure, 
inputs  and  outputs  are  matched  by  drawing  lines.  As  illustrated, 
one  input  can  result  in  one  or  many  outputs. 
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Inputs 

Outputs 

Customer  Order _ 

►  Requested  Customer  Product 

Customer  Inquiry 

> 

^  Request  for  Supplier  Quotes 

Requested  Supplies  / 

^  Response  to  Customer  Inquiry 

Supplier  Bids 

Supplier  Delivery  Order 

Ancillary  Inputs  and 
Outputs 


Identify  and  Name 
Processes 


Figure  3.1-4.  Example  of  Input/Output  Matching 

Inputs  and  outputs  may  be  further  classified  as  primary  or 
ancillary.  Primary  I/O's  have  a  direct  impact  on  the  customer 
request  and  typically  signify  process  completion.  Ancillary  I/O's 
represent  a  means  of  gathering  more  information  or  services  from 
outside  (external)  business  suppliers  and  may  be  referred  to  as 
ancillary  events. 

By  organizing  the  inputs  and  outputs,  naming  the  processes,  and 
identifying  sources  and  destinations,  the  process  diagram  evolves. 
Figure  3.1-5  illustrates  responses  to  the  receipt  of  a  customer  order 
and  establishes  a  fundamental  business  process  named  "Fill 
Customer  Order".  Note  that  process  names  are  generally  action 
oriented  with  a  verb  as  the  initial  word. 
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Sub-Processes 


Figure  3.1-5.  Business  Process  Level  Diagram 


A  look  deeper  into  this  business  process  (shown  in  Figure  3.1-6) 
indicates  ancillary  sub-processes.  Sub-processes  fit  the  definition 
of  a  process,  but  exist  to  facilitate  completion  of  the  primary 
processes  included  in  the  business  value  stream  (discussed  in 
section  3.1.3).  In  the  example,  either  the  business  has  the  ability  to 
directly  respond  to  the  customer  with  the  product  requested  (see 
the  "Fill  In-Stock  Customer  Order"  sub-process)  or  the  business 
must  obtain  the  services  of  an  outside  supplier  to  provide  necessary 
parts  before  responding.  As  a  result,  the  business  requests 
quotes/bids  from  the  supplier  for  needed  parts  and  determines 
which  supplier  provides  the  best  possible  service  and  price  (see 
"Select  Qualified  Supplier"  sub-process).  Once  the  needed  parts  are 
received,  the  original  customer  order  or  backorder  is  filled  (see 
"Fill  Customer  Back  Order"  subprocess). 
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Figure  3.1-6.  Process  vs.  Sub-process 


Avoid  Process  Details 


This  chain  of  primary  and  ancillary  processes  represents  the 
foundation  of  the  business  value  stream. 

The  advantage  of  using  such  a  primitive  approach  is  that  it  does 
not  allow  the  team  to  get  bogged  down  in  the  details  of  process 
operation.  Other  techniques,  such  as  event  tracking,  involve  the 
systematic  decomposition  of  a  business  process. 

Detailed  process  definition  is  not  required  during  process 
identification,  but  will  be  further  addressed  in  Chapter  4  of  this 
document. 


3.1.3.  Understand  the  business  Enterprise  Value  Stream 


Value  takes  many  forms  within  an  organization.  The  assessment  of 
business  processes  with  respect  to  business  value  leads  to  a 
discussion  of  the  business  value  stream. 


3.I.3.I.  Definition  of  the  Business  Value  Stream 

The  phrase  business  value  stream,  refers  to  the  set  of  all  business 
processes  required  to  satisfy  a  customer  request  or  to  directly 
provide  customer  service.  As  a  general  rule,  the  business  value 
stream  starts  with  a  customer  and  ends  with  the  same  customer. 
How  a  business  is  perceived  by  customers  is  directly  dependent  on 
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Process  Chains 


the  performance  and  quality  of  processes  identified  within  the 
business  value  stream. 


Figure  3.1-7.  Customer  Perception  of  a  Business  Enterprise 


Customer  perceptions  drive  product  demand,  influence  market 
share,  and  impact  product  cost.  In  general,  customers  are  not 
concerned  with  process  problems,  just  process  results  in  the  form 
of  quality  products  and  services. 

The  business  value  stream  may  consist  of  one  or  many  business 
processes  (primary  or  ancillary)  chained  together  to  create  the 
desired  business  response.  Consider  the  previous  example  of  a 
customer  order,  expanded  in  the  Figure  3.1-8.  If  the  materials  are 
available  for  completion  of  the  customer  order,  then  the  requested 
product  is  sent  to  the  customer  and  the  business  value  stream  is 
completed. 


Figure  3.1-8.  Business  Value  Stream  Initiation 

If  the  business  must  stop  to  wait  for  outside  materials,  then  a 
temporary  suspension  of  the  business  value  stream  occurs,  until 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


Page  52 


CHAPTER  3.  IDENTIFICATION  &  ASSESSMENT 


material  arrives  and  the  value  stream  continues.  As  a  result,  a  chain 
of  business  processes  may  be  required  to  ultimately  complete  the 
customer  order. 

Upon  a  preliminary  business  review,  CSK  identified  a  set  of 
primary  business  processes  as  part  of  the  business  value  stream. 
Primary  business  processes  were  later  decomposed  into  ancillary 
subprocesses.  Figure  3.1-9  illustrates  the  primary  processes 
discussed  in  further  detail  within  this  document. 


Team  Member, 
Customer, 
[nformation  Source 


Develop 

Winning 

Proposal 


Product/Service 

Delivery 


^Vncillary 

Event 


f  Construct  and  * 
■  Deliver  Customer 
L  Solution 


Request 

for 

Cost 

Estimates 


V 

Reque: 


Cost 

Estimates 
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Supplier 

Parts/Services 


Supplier 

Parts/Services 


Figure  3.1-9.  CSK  Example  :  Value  Stream  Processes 


Notice  that  the  business  process  view  is  not  cluttered  by  details  of 
physical  implementation,  and  therefore,  represents  both  a  logical 
and  physical  process  view. 

Value  Stream  F eedback  Feedback  should  not  be  under  emphasized  as  a  critical  part  of  the 

business  value  stream.  Feedback  may  be  received  from  suppliers 
and/or  customers  relating  to  specific  interfaces  with  each. 
Integration  of  feedback  is  critical  in  creating  a  "closed-loop" 
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design,  allowing  the  enterprise  to  progressively  learn  from  and 
adapt  to  outside  influences. 

3. 1.3.2.  Impact  of  Suppliers  on  the  Business  Value  Stream 

As  shown  in  the  previous  figures,  the  business  value  stream  is 
often  interrupted  to  wait  for  support  from  suppliers.  The  impact  of 
suppliers  on  a  business  process  can  be  either  positive  or  negative. 
Each  time  a  business  must  request  support  from  a  supplier 
(business  process  output),  the  existing  business  process  is  altered, 
often  forming  a  new  process  to  receive  supplier  goods  and 
continue  the  business  value  stream.  Therefore,  the  decision  of 
whether  to  utilize  outside  suppliers  of  goods  or  services  is  critical 
to  a  business  enterprise,  since  such  decisions  shape  the  number  and 
definition  of  processes  for  the  enterprise. 

Supplier  Commitment  Today  there  are  many  business  trends  leaning  towards  outsourcing 

of  services.  The  term  "outsourcing" ,  refers  to  dependence  on 
outside  suppliers  for  goods  and/or  services  instead  of  performing 
the  service  within  the  business  itself.  For  years,  TQM 
methodologies  have  promoted  the  idea  of  working  with  suppliers 
in  a  cooperative  manner  to  improve  overall  process  and  product 
quality.  Point  Four  of  Dr.  Edward  Deming's  "  Fourteen  Points  for 
Management "  recommends  that  businesses: 

End  the  practice  of  awarding  business  on  price  tag 

■ '  '•  '  •  ' 

alone.  Instead,  minimize  total  cost  by  working  with  a 
single  supplier. 

This  single  sourcing  concept  is  meant  to: 

•  reduce  variation 

•  reduce  administrative  costs  related  to  working  with  multiple 
suppliers 

•  promote  trust  and  confidence,  which  fosters  two-way 
communication 

This  supplier  commitment  may  include  helping  supplier(s)  to 
become  more  efficient  through  reengineering.  Each  supplier  should 
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be  considered  a  value-added  partner  within  the  business  value 
stream  or  supplier  processes  should  be  considered  for  consumption 
by  the  process  and  performed  by  activities  within  the  business 
enterprise. 

Supplier  Consumption  Some  businesses  prefer  to  reduce  the  amount  of  outsourcing  by 

performing  more  activities  in-house.  The  advantage  to  consuming 
supplier  activities  relates  to  control.  The  business  enterprise  gains 
control  over  the  entire  business  value  stream  including  those 
activities  previously  outsourced.  Conversely,  the  disadvantage  lies 
in  the  need  for  the  business  to  become  efficient  in  previously 
outsourced  activities,  many  times  resulting  in  large  learning  curves 
and  start-up  costs. 


Process  Expansion 


Committment,  Partnership,  (Outsourcing) 


Figure  3.1-10.  Business  Supplier  Relationships 

3.1.4.  Describe  business  Processes 

For  each  business  process  identified,  a  business  process  description 
is  then  created  that  inherently  communicates  the  business  process 
characteristics.  Most  business  process  descriptions  will  consist  of 
only  a  few  sentences  and  be  similar  in  construction. 
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Record  Business  Process 
Description 


For  a  simple  example,  fill  in  the  highlighted  words  to  the 
following: 

"This  process  is  initiated  upon  receipt  of  INPUT  from 

SOURCE/SUPPLIER.  Upon  receipt  of 

liii  , 

process  must . 


How  Much  Description 
is  Enough? 


While  many  process  descriptions  will  be  more  complex  than  the 
example  provided,  too  much  complexity  typically  implies  that  the 
process  has  been  over  described.  As  a  self-check,  ask  the 
following: 

•  Is  the  description  clear?  Provides  for  a  clear  understanding 
of  business  process  mission  and  boundaries. 

•  Is  the  description  repeatable?  Provides  a  definition  which,  if 
used  properly  by  different  individuals,  would  result  in  the 
same  process  boundaries 

•  Does  the  description  include  the  fundamental  characteristics 
of  a  business  process?  Includes  external  input,  required 
processing,  external  output(s). 

Effective  identification  and  description  of  business  processes  will 
typically  result  in  a  small  number  of  processes.  Having  less  than 
ten  business  processes  should  not  be  alarming  and  does  not  imply 
the  business  is  less  complex.  Since  business  processes  terminate 
when  processes  stop  to  gather  resources  from  external  suppliers, 
businesses  which  utilize  outside  suppliers  for  many  business 
operations  will  tend  to  have  more  business  processes. 

One  of  the  first  processes  identified  by  CSK  was  that  of  responding 
to  a  request  for  proposal,  identified  here  with  the  process  name  of 
"Develop  Winning  Proposal”.  An  abbreviated  process  description 
and  an  enterprise  level  process  view  is  provided  in  Figure  3.1-1 1. 
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Develop  Winning  Proposal 


Process  Description:  This  process  is  initiated  upon  receipt  of  a  Request 
for  Proposal  (RFP)  from  a  potential  team  member,  potential  customer,  or 
a  known  information  source.  Upon  RFP  receipt,  the  business  must: 

•  record  critical  RFP  information 

•  make  a  bid  decision 

•  establish  technical  design  requirements 

•  integrate  accurate  time  and  cost  estimates 

•  prepare  and  deliver  a  winning  proposal 


Team  Member, 
Customer, 
Information  Source 


/a 

Request  1 

foj-  Proposal 


Figure  3.1-11.  CSK  Example  : Process  Overview  Example 


Notice  that  this  process  is  accompanied  by  ancillary  inputs  and 
outputs  required  to  gather  supplier  estimates.  Delivery  of 
customized  solutions  by  CSK  is  dependent  on  Just-In-Time  (JIT) 
delivery  response  from  suppliers,  as  well  as  accurate  costing. 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


Chapter  3.  identification  and  Assessment 


Page  57 


3.2.  Assess  Business  Processes 

The  technical  assessment  of  business  processes  must  consider 
many  issues  and  represents  a  form  of  a  business  self  check-up. 
Critical  issues  to  consider  include: 

•  the  purpose  of  a  business  process  with  respect  to  the 
business  enterprise  value  stream 

•  the  impact  of  the  business  process  on  business  goals  and 
targets,  referred  to  in  this  document  as  business  process 
impact 

•  the  health  of  a  business  process  as  perceived  by  customers 
(internal  and  external)  and  those  who  have  ownership  of 
process  operations.  The  business  process  health  refers  to  the 
degree  to  which  a  business  process  must  change  to  reach  the 
desired  business  goals  and  targets. 

Each  of  these  topics  is  addressed  in  further  detail  in  the  following 
subsections. 

3.2.1.  DETERMINE  BUSINESS  PROCESS  IMPACT  ON  GOALS/TARGETS 

Once  a  set  of  business  processes  has  been  identified  and  defined, 
and  the  business  value  stream  (the  set  of  customer  driven  -  primary 
processes)  is  identified,  process  assessment  actions  may  begin. 

The  goal  of  this  stage  is  to  rate  the  impact  of  a  business  process  on 
the  business  goals  and  targets  established  in  Section  2.3.3.  Ratings 
will  likely  be  customized  to  meet  the  needs  of  a  specific  business. 
Ratings  can  be  as  simple  as  assigning  a  low,  medium,  or  high  rank 
to  each  process  and  then  ranking  ranking  processes  according  to 
assigned  ratings.  Such  ratings  are  typically  established  in  a  team 
setting,  by  form  of  consensus.  More  complex  ratings  may  involve 
establishing  a  grid/matrix  of  numerical  values  relating  to  each 
business  goal.  The  resulting  values  are  added  together  to  form  a 
figure  of  merit  for  each  process.  Table  3.2  lists  figures  of  merit 
(assigned  between  0  as  the  low  and  100  as  the  high)  for  each 
process  and  business  goal,  along  with  a  total  figure  of  merit. 
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Table  3.2.  Figure  of  Merit  Values  for  Business  Processes 


Process 

Goal  1 

Goal  2 

Goal  3 

Goal  4 

Total 

Process  1 

85 

55 

60 

80 

70 

Process  2 

62 

55 

45 

38 

50 

Process  3 

81 

79 

89 

71 

80 

Process  4 

43 

48 

57 

52 

50 

Process  5 

13 

10 

7 

10 

10 

Case  Study 


Record  Process  Impact 
Values 


Organizations  may  choose  to  rate  processes  in  a  qualitative 
manner,  simply  placing  the  processes  in  relative  order  of 
importance. 

CSK  goals,  including  dramatic  increases  in  gross  revenues  and 
minimal  increases  in  staff,  were  used  as  yardsticks  for  process 
assessment.  Business  value  stream  processes  including  "Develop 
Winning  Proposal"  and  "Construct  and  Deliver  Customer 
Solution"  were  noted  to  have  the  greatest  impact  on  critical 
business  goals.  Ancillary  processes  supporting  administrative 
activities  such  as  payroll  and  accounting  were  noted  for  later 
consideration. 

Judging  process  improvements  over  time  requires  that  basic 
process  metrics  be  established.  The  values  (figures  of  merit)  for 
impact  and  health  developed  as  part  of  this  and  the  following 
section  represent  metrics  which  can  be  useful  as  comparisons 
during  future  process  reviews.  Recording  this  information  in  the 
Process  Management  Notebook  (PMN)  provides  an  excellent  way 
of  capturing  this  critical  information. 


3.2.2,  DETERMINE  BUSINESS  PROCESS  HEALTH 

For  the  purpose  of  this  document,  process  "health"  and  process 
"quality"  are  directly  related.  Process  health  refers  to  the  ability  of 
a  business  process  (in  its  current  form)  to  meet  the  desired  business 
goals  and  targets.  Higher  quality  processes  are  generally  efficient 
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3.2.2. 1.  Process  Quality 


Level  of  Process  Review 


Methods  of  Assessment 


in  nature  and  produce  high  quality  products.  The  opposite  is  true 
for  lower  quality  processes.  In  order  to  achieve  breakthroughs, 
business  processes  which  are  in  the  greatest  need  of  change  must 
receive  the  most  attention.  Such  processes  represent  low  quality  (or 
unhealthy  processes). 


Business  process  health  is  determined  by  evaluating  quality 
factors.  Garvin,  in  his  book  entitled  " Managing  Quality",  refers  to 
five  quality  categories  including: 

1.  Transcendent:  Subjective  feeling  of  "goodness" 

2.  Product-based:  Measured  by  attributes  of  the  product 

3.  Manufacturing-based:  Measured  by  conformance  to 
specification 

4.  Value-based:  Determined  by  "goodness"  for  price  of  the 
product 

5.  User-based:  The  capacity  to  satisfy  the  customer. 

Note  that  the  categories  are  not  mutually  exclusive  and  that 
successfully  achieving  high  quality  in  one  category  may  lead  to 
reduced  quality  in  another  category.  Just  meeting  specification 
limits  (manufacturing-based)  for  a  product  may  not  meet  customer 
expectations  (user-based). 

Process  assessment  need  not  include  a  detailed  process  analysis. 
The  goal  at  this  stage  is  to  gather  enough  information  to  accurately 
determine  which  processes  are  the  most  unhealthy.  In  many  cases, 
processes  have  been  pre-selected  based  on  a  continuous  inability  to 
meet  management  or  customer  expectations. 

Further  detail  relating  to  process  evaluation  is  discussed  in  section 
4.3  of  this  document. 

Many  times  it  is  difficult  to  determine  whether  problems  identified 
within  a  business  will  be  solved  by  improving  a  given  process. 
Tools  such  as  an  affinity  diagram  (shown  in  the  Figure  3.2-1)  may 
prove  to  be  useful  in  organizing  poorly  defined  problems  into 
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groups  which  can  be  more  easily  assigned  to  processes.  As  a  result, 
a  quick  list  of  health  problems  may  be  formed  which  can  be  used 
to  verify  process  health  and  be  fed  as  input  to  later  evaluation  and 
design  stages. 


The  use  of  Affinity  diagrams  is  discussed  in  further  detail  in 
section  5.3.3. 1  of  this  document. 


Quality  of  Process  The  following  questions  must  be  answered  in  order  to  determine 

Process  Check-Up  process  health. 


•  How  does  management  and  staff  perceive  the  process? 
(Perceived  as  broken,  out  of  control,  etc.) 

•  How  does  the  end  product(s)  of  the  process  compare  to  those 
of  competitors? 

•  How  much  rework  is  performed  or  how  many  defects  are 
produced  by  the  process? 


Case  Study  || 


•  How  does  the  price  of  the  product  compare  to  those  of 
competitors? 

CSK  planned  to  expand  marketing  initiatives,  but  was  concerned 
and  convinced  that  the  resulting  workflow  would  overburden  the 
existing  workforce.  A  cursory  look  at  business  processes  indicated 
that  the  majority  of  workflow  effort  to  support  generation  of 
proposals  centered  within  product  design  activities.  In  addition, 
analysts  and  management  noted  that  product  design  activity  for 
proposals  and  product  design  activity  for  completing  customer 
contracts  was  shared.  Based  on  this  cursory  review,  CSK  noted 
that  dramatic  changes  would  be  required  to  both  the  "Develop 
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Winning  Proposal"  and  " Construct  and  Deliver  Customer 
Solution"  processes  in  order  to  meet  business  goals. 

3.2.2.2.  Cost/Economic  Assessment 

Many  businesses  will  choose  to  utilize  cost  indicators  to  determine 
process  health.  Cost  analysis  and  approaches  such  as  Functional 
Economic  Analysis  (FEA)  review  the  cost  potential  of  solutions  to 
common  process  problems.  This  form  of  study  can  be  extremely 
helpful  in  reviewing  processes  where  both  problems  and  solutions 
are  known  up-front,  or  where  better  understanding  of  the 
economics  of  the  "status  quo"  will  help  to  determine  process 
health.  A  process  which  represents  a  considerable  cost  risk  to  leave 
"as- is"  may  prove  to  be  an  increased  health  risk  over  time  for  a 
business. 

3.2.3.  IDENTIFY  LINKAGE  BETWEEN  BUSINESS  PROCESSES 

Previous  discussions  of  the  business  value  stream  stressed  the 
relationship  between  key  processes,  chained  together  to  meet 
customer  needs.  As  a  result  of  this  stream  of  processes, 
dependencies  between  processes  are  identified.  Processes  which 
are  highly  dependent  on  each  other  form  a  cohesive  bond,  making 
them  inseparable  for  reengineering. 

Order  of  Precedence  The  linkage  between  processes,  and  the  resulting  order  in  which 

they  occur,  should  be  considered  prior  to  selecting  process  for 
reengineering.  Ancillary  processes  (those  which  represent  the 
major  source  of  materials  for  subsequent  processes)  are  often 
addressed  earlier  to  pave  the  way  for  actual  process  targets.  A  low 
quality  process  early  in  the  process  chain  may  contaminate  later 
processes  with  bad  information  and/or  resources,  which  prohibit 
the  desired  breakthrough  improvements. 

3.3.  Select  Business  Processes  for  Reengineering 

The  goal  of  this  stage  of  process  assessment  is  to  select  the  most 
appropriate  processes  for  reengineering.  For  most  organizations, 
the  decision  relating  to  process  selection  is  relatively  easy.  Either 
the  values  assigned  to  impact  or  health  are  overwhelmingly  in 
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favor  of  reengineering,  or  the  cost  of  maintaining  the  "status  quo" 
make  reengineering  an  immediate  priority. 

Process  Selection  Matrix  a.  relatively  simple  approach  to  review  process  parameters  is  to 

establish  a  matrix  of  process  impact  vs.  process  health.  This 
process  selection  matrix  provides  visibility  into  which  processes 
are  the  strongest  candidates  for  reengineering.  The  following 
diagram  illustrates  a  simple  example  of  a  process  selection  matrix. 
The  complexity  of  such  a  matrix  will  depend  on  the  complexity  of 
values  assigned  to  process  impact  and  process  health. 


Figure  3.3-1.  Process  Selection  Matrix 

Additional  tools  may  be  useful  in  making  comparisons  between 
different  process  parameters.  A  variety  of  analysis  tools  are 
outlined  in  Chapter  5  of  this  document. 

Team  members  may  also  wish  to  utilize  additional  methods  for 
ranking  of  processes  such  as  the  Nominal  Group  Technique  (NGT) 
described  further  in  section  4.2.1  of  this  document. 
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CSK  selected  both  the  "Develop  Winning  Proposal"  and 
"Construct  and  Deliver  Customer  Solution”  processes  for 
simultaneous  reengineering,  with  an  initial  focus  towards  product 
design.  This  simultaneous  approach  was  deemed  necessary  due  to 
the  high  degree  of  linkage  between  processes  and  subordinate 
activities.  In  addition,  CSK  noted  common  process  problems  such 
as  data  redundancy  for  more  further  investigation  during  process 
analysis  and  design  activities. 

3.4.  ESTABLISH  A  PROCESS  ACTION  TEAM 

Once  a  process  has  been  selected  for  reengineering,  a  strong  team 
is  required  to  support  further  evaluation,  redesign,  and 
transformation. 

Process  Action  Teams,  or  PATs,  represent  the  foundation  of  a 
process  focused,  participative  management  environment.  A  PAT  is 
a  group  of  individuals  who  work  together,  using  shared  knowledge 
and  capabilities,  to  improve  business  processes.  In  the  "Wizdom  of 
Teams"  written  by  Katzenbach  and  Smith,  a  team  is  defined  as: 

...  a  small  number  of  people  with  complementary  skills 
who  are  committed  to  a  common  purpose,  set  of 
performance  goals,  and  approach  for  which  they  hold 
themselves  mutually  accountable 

Creating  an  effective  team  and  the  appropriate  environment  in 
which  the  team  can  flourish  can  be  a  challenge  on  its  own. 

Team  Members  A  PAT  will  commonly  consist  of  individuals  with  the  following 

characteristics: 

•  knowledgeable  about  the  process 

•  owner(s)  of  the  process 

•  customer(s)  of  the  process 

•  supplier(s)  of  the  process 

Typically,  a  PAT  leader  is  assigned  to  guide  team  activities.  When 
the  organization  is  not  experienced  in  TQM  principles,  a  facilitator 
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('  Case  Study  II 
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(commonly  an  experienced  consultant)  is  recommended  as  a 
mechanism  to  create  team  synergy. 

Details  relating  to  the  concept,  organization,  and  implementation 
of  process  action  teams  can  be  found  in  the  "Process  Action  Team 
Handbook" ,  published  by  the  Reliability  Analysis  Center. 

Team  Flexibility  The  team  structure  should  be  flexible  in  nature,  allowing  for  the 

addition  of  new  members  or  replacement  of  existing  members  as 
necessary  to  encourage  maximum  coordination,  cooperation,  and 
communication. 

Team  Responsibilities  PATs  not  only  support  reengineering  activities,  but  also  support 

evolution  of  business  processes  after  reengineering  is  completed. 


Record  Team 
Charter/Responsibilities 


During  reengineering,  PAT  members  carry  the  responsibility  of 
establishing  a  new  process  design  which  will  meet  desired  business 
goals  and  targets. 

PAT  responsibilities  should  be  documented  in  a  clear  and  concise 
manner.  Documentation  should  provide  team  members  with: 

•  understanding  of  team  mission 

•  definition  of  individual  roles  with  respect  to  the  team 

•  understanding  of  the  conduct  and  environment  expected 
within  the  team 


CSK  Example:  Process 
Action  Teams  (PATs) 

4  ^  ■ 

Case 


•  understanding  of  the  limits  and  latitude  the  team  has  for 
carrying  out  targeted  actions 

CSK  established  flexible  PATs  to  support  reengineering  efforts  for 
business  processes  and  associated  activity  sets.  Each  of  the  teams 
was  customized  based  on  the  size,  complexity,  and  availability  of 
staff.  Generally,  team  structures  consisted  of  a  process  champion 
and  several  process  workers.  In  addition,  ERT  members,  including 
the  independent  consultant  and  the  manager  of  information 
systems  are  considered  de  facto  members  of  teams,  ensuring  that 
processes  achieve  the  level  of  integration  required  during 
reengineering  efforts. 
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Where  Am  I? 


Chapter  Overview 


At  this  point  of  BPR,  a  high  impact  (critical)  business  process  has 
been  selected  for  reengineering.  In  addition,  the  process  selected 
has  often  been  identified  as  an  opportunity  for  breakthrough  due  to 
the  disparity  between  its  current  operational  status  and  that  which 
will  meet  business  success  targets,  referred  to  as  business  process 
health.  Key  ingredients  to  the  innovation  and  redesign  stage 
include  the  products  of  previous  stages  as  illustrated  in  the 
following  diagram. 


Figure  4-1.  Overview  of  Innovation  and  Redesign 


This  chapter  discusses  the  principles  and  concepts  surrounding 
business  process  innovation  and  redesign  including: 

•  innovation  approach 

•  establishing  a  process  vision 

•  process  modeling 
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CHAPTER  4.  INNOVATION  &  REDESIGN 


4.1.  innovation  Approach 

Webster's  dictionary  defines  innovation  as: 

" the  introduction  of  something  new " 

To  be  truly  innovative,  a  business  must  foster  a  new  thinking 
environment.  A  thinking  environment  is  one  where  each  individual 
within  a  business  enterprise  understands  the  need  for  change  and 
continually  uses  creativity  combined  with  process  knowledge  and 
technology  awareness  to  create  the  next  generation  business 
process. 

Gregory  Watson,  in  his  book  entitled  "Business  Systems 
Engineering" ,  provides  the  following  insight  relating  to  innovation. 

Productivity  —  the  key  to  business  profitability  --  is  the 
result  of  how  we  manage  the  process  for  producing 
goods  and  services  and  is  driven  by  implementing 

mi tiiii  la®® i  mil i ?n iiiiiiii  ws iiiii . ..  i 

innovations  in  both  products  and  their  customer  driven 
processes  ■ . sSKj?  ;  :  1  11  : 

This  section  is  not  meant  to  establish  a  restrictive  method  for 
innovation  of  new  process  designs,  but  rather  to  characterize  the 
type  of  thinking  (non-traditional)  necessary  to  allow  creativity  and 
speed  transformation. 

4.1.1.  Traditional  Systems  Engineering 

Traditional  systems  engineering  approaches  typically  follow  a  rigid 
"waterfall"  type  model.  This  approach  demands  that  all 
requirements  be  defined  prior  to  formulating  a  design  and  that  the 
design  phase  is  completed  prior  to  initiating  the  development 
phase.  The  waterfall  approach,  as  illustrated  in  Figure  4.1-1,  results 
in  a  series  of  linear  development  steps,  slowing  the  delivery  of  the 
end  product  to  customers.  In  fact,  for  most  large  scale  system 
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Radical  Simply  Means 
Non-  Traditional 


Reshaping  Processes 


developments,  such  a  linear  approach  will  yield  a  system  which  is 
out-dated  before  it  is  deployed. 


_  I 

Figure  4.1-1.  Traditional  Systems  Engineering  Approach 


Business  Process  Reengineering  is  considered  radical  for  a  variety 
of  reasons,  but  primarily  because  of  the  following: 

•  When  existing  processes  are  rethought  from  scratch,  the 
resulting  new  process  design  often  does  not  resemble  the 
existing,  traditional  process  design.  This  design  gap  may  be 
broad  in  nature  and  difficult  for  the  general  population  to 
grasp. 

•  To  innovate  new  process  designs  and  transform  the  business 
in  a  rapid  manner,  traditional  approaches  and  the  status  quo 
are  intentionally  avoided  to  support  more  iterative,  real-time 
engineering.  Many  in  the  organization  view  the  departure 
from  the  norm  as  " breaking  the  rules",  rather  than  "changing 
the  rules" . 

True  innovations  may  also  lead  to  redefinition  or  rescoping  of  a 
business  process.  Rescoping  may  include  changing  the  process 
boundaries  due  to  integration  with  suppliers  or  expansion  in 
services  provided.  An  article  presented  in  the  March  1995  issue  of 
Business  Week  documents  how  VF  Corporation  (the  maker  of  Lee 
Jeans)  reengineered  market  response  systems  to  replenish  retailer 
shelves  faster  and  more  cost  effectively  than  competitors.  Such  an 
innovation  did  not  involve  mass  changes  to  the  existing  production 
process,  but  a  rescoping  of  the  production  and  distribution  process 
boundaries  to  interface  directly  with  customers,  monitoring 
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The  80-20  Principle 


immediate  market  needs.  Basically  the  idea  was  to  provide  Just-In- 
Time  (JIT)  products  along  with  Just  What  You  Need  products.  The 
new  process  monitors  sales  by  major  retailers  (J.C.  Penney,  Wal- 
Mart,  etc.)  and  automatically  reorders  and  restocks  products  for 
retailers  to  meet  the  exact  purchase  patterns  of  customers.  If  Wal- 
Mart  sells  a  pair  of  jeans  today,  a  replacement  pair  is  back  on  the 
shelf  by  late  tomorrow.  The  process  change  required  that  suppliers 
and  customers  work  together  to  create  process  responses  with 
mutual  benefits. 

The  80-20  principle  or  Pareto  Principle  refers  to  the  concept  that 
the  majority  of  value  achieved  from  an  effort  may  be  attributed  to 
only  a  limited  portion  of  the  expended  effort.  As  a  general  rule, 
80%  of  the  process  requirements  are  defined  quickly,  using  only 
20%  of  the  overall  time  and  resources  needed  to  complete  detailed 
analysis  (requirements  definition).  Using  the  same  principle  in 
reverse,  80%  of  the  time  spent  on  requirements  definition  delivers 
only  20%  of  the  requirements.  In  addition,  the  initial  requirements 
defined  are  commonly  more  logical  in  nature  and  therefore  less 
likely  to  change.  Effective  application  of  these  common  principles 
leads  to  the  deployment  of  solutions  within  the  same  time 
previously  required  to  complete  new  process  designs.  Figure  4.1-2 
shows  a  simplified  view  of  how  the  80-20  principle  can  be  used  to 
condense  the  time  spent  on  delivering  a  new  process  design.  Each 
subsequent  phase  is  initiated  after  significant  results  has  been 
completed  (approximately  80%),  yet  only  a  limited  amount  of 
effort  (approximately  20%)  has  been  expended. 
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Figure  4.1-2.  80-20  Application  to  Design  Delivery 


While  the  use  of  the  80-20  rule  does  not  apply  to  every  situation, 
the  concept  of  80-20  provides  a  flexible  development  approach 
with  emphasis  on  quickly  evaluating  what  you  think  you  know. 

4.1.2.  Concurrent  Engineering 

In  recent  years,  businesses  have  migrated  to  forms  of  concurrent 
engineering.  In  a  report  published  by  the  Institute  for  Defense 
Analysis  entitled  "The  Role  of  Concurrent  Engineering  in  Weapons 
Systems  Acquisition" ,  concurrent  engineering  is  defined  as: 

Concurrent  engineering  is  a  systematic  approach  to  the 
integrated,  concurrent  design  of  products  and  their 
related  processes,  including  manufacturing  and 
support.  This  approach  is  intended  to  cause  the 
developers,  from  the  outset,  to  consider  all  elements  of 
the  product  life  cycle  from  conception  through 
disposal,  including  quality,  cost,  schedule,  and  user 
requirements. 
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Concurrent  engineering  reduces  the  focus  on  a  serial  engineering 
process  and  leverages  strong  communication  between  product  and 
process  design  as  illustrated  in  the  Figure  4.1-3. 

Requirement 

Product  Development 

Process  Development 
Prototype 


Time 

Figure  4.1-3.  Concurrent  Engineering  Overview 


4.1.3.  TECHNICAL  STRATEGIES 

A  variety  of  terms  and  strategies  are  often  associated  with  process 
reengineering  or  process  redesign  such  as: 

•  software  reengineering 

•  restructuring 

•  reverse  engineering 

•  retargeting 

•  forward  engineering 

•  data  reengineering 

Successful  process  redesign  often  includes  a  combination  of  these 
strategies  used  to  various  degrees. 

Many  of  the  strategies  and  terms  are  the  by-product  of  efforts 
directed  towards  "software  reengineering".  The  Software 
Reengineering  Assessment  Handbook  (SRAH)  published  by  the 
Air  Force  Software  Technology  Support  Center  (STSC)  describes 
the  steps  required  to  determine  which  (if  any)  reengineering 
strategy  should  be  used  with  respect  to  a  given  existing  system. 
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Software  Reengineering 


The  term  reengineering  is  often  misleading  if  not  prefaced  with 
either  Business  Process  or  Software.  Business  Process 
Reengineering  should  not  be  confused  with  Software 
Reengineering.  Software  Reengineering  is  a  subset  of  BPR  and 
may  be  used  to  convert,  replace,  or  enhance  existing  systems. 
Many  of  the  concepts  applied  to  BPR  can  also  be  applied  to 
software  reengineering  with  a  different  scope.  Figure  4.1-3 
illustrates  the  scope  of  BPR  versus  that  of  software  reengineering. 


Figure  4.1-4.  Scope  of  BPR  vs.  Software  Reengineering 

Software  reengineering  without  a  business  process  focus  is  not 
recommended  and  may  result  in  wasted  effort.  For  example, 
reengineering  existing  software  to  create  administrative  reports 
may  be  unnecessary  if  analysis  of  the  business  process  indicates 
that  the  administrative  reports  are  not  value-added  and  scheduled 
for  removal. 
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Restructuring 


Reverse  Engineering 
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Retargeting 


Forward  Engineering 


Data  Reengineering 


Restructuring  refers  to  the  reorganization  of  people,  systems,  and 
infrastructure  to  perform  the  same  basic  functions  in  a  more 
efficient  manner.  Restructuring  often  has  a  more  significant  impact 
on  the  social  design  (culture  and  associated  environment)  than  the 
technical  design  of  a  process.  Restructuring  alone  will  typically  not 
result  in  breakthroughs  in  performance  but  may  lead  to  process 
improvements.  When  used  with  respect  to  software,  restructuring 
often  relates  to  reorganization  of  source  code. 

Reverse  Engineering  refers  to  the  extraction  of  the  existing  design 
from  the  current  implementation.  As  a  rule  of  thumb,  reverse 
engineering  will  result  in  an  "as-is"  view  of  the  system. 

Section  4.3  provides  further  insight  into  reverse  engineering  with 
respect  to  BPR. 

Retargeting  is  predominantly  used  as  part  of  software 
reengineering  to  describe  the  transport  of  existing  source  code 
(software)  to  a  new  host  system.  The  emphasis  on  downsizing  of 
legacy  systems  makes  common  use  of  the  retargeting  concept. 
Some  organizations  are  considering  the  use  of  retargeting  at  a 
business  process  level;  the  results  would  include  transporting 
business  processes  to  entirely  new  locations,  buildings,  and 
environments.  With  the  existing  organizational  culture  being  a 
primary  barrier  to  change,  creating  a  new  culture  at  a  different  host 
location  may  be  a  strategy  which  gains  more  attention. 

The  design  or  redesign  of  a  new  business  process  to  include 
remnants  of  the  existing  process  design  (the  "as-is"  design  which 
may  be  derived  via  reverse  engineering)  and  new  business  process 
requirements.  Forward  Engineering  commonly  applies  when 
process  boundaries  are  modified.  For  example,  if  a  business 
process  previously  relied  on  outside  suppliers  to  provide  materials, 
forward  engineering  may  include  the  expansion  of  process 
boundaries  to  include  production  of  the  once  supplier  based 
materials  previously  produced  by  suppliers. 

Data  Reengineering  refers  to  the  reorganization  of  information  to 
support  either  manual  or  automated  business  process 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


CHAPTER  4.  INNOVATION  &  REDESIGN 


Page  75 


improvements.  Such  reorganization  can  refer  to  construction  of 
automated  databases  or  simply  centralized  access  to  commonly 
used  physical  documents. 

4.1.4.  real-time,  Evolutionary  Engineering 

With  an  understanding  of  the  traditional  engineering  approaches 
and  common  reengineering  strategies  as  input,  innovation  may 
begin.  The  challenge  is  to  establish  an  approach  which  places  less 
emphasis  on  formal  documentation  and  milestones  and  more 
emphasis  on  delivering  desired  functionality  to  customers  (internal 
and  external).  In  essence,  reengineering  represents  a  form  of  rapid 
evolution,  a  recreation  of  the  evolutionary  process  within  an 
extremely  condensed  time  frame. 

Figure  4.1-4  illustrates  the  interactions  between  each  of  the  key 
steps  necessary  for  successful  innovation  and  redesign,  along  with 
key  inputs  and  outputs.  A  brief  summary  of  each  of  the  steps  is 
provided  in  the  following  paragraphs  and  further  detailed  in  the 
subsections  within  this  chapter. 
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An  ideal  process  vision  represents  the  foundation  for  creating  new 
process  designs.  A  process  vision  is  established  which  incorporates 
the  logical  requirements  of  the  process  without  respect  to  business 
constraints  and  describes  the  features  which  can  be  imagined 
relating  to  how  the  process  may  perform.  To  some  analysts,  this 
may  be  extended  to  form  a  logical  process  model. 

With  a  process  vision  in-hand,  innovators  may  wish  to  jump 
directly  to  designing  a  new  process  (redesign)  using  clean-slate 
thinking  or  examine  the  existing  process  design  more  thoroughly  to 
identify  existing  design  strengths  and  weaknesses. 

Process  visions  are  addressed  more  thoroughly  in  Section  4.2  of 
this  document. 

Many  organizations  prefer  to  start  by  examining  the  existing 
business  process  in  more  detail.  If  an  existing  process  model  is  not 
available,  most  find  it  necessary  to  generate  an  "as-is"  process 
model  and  use  this  model  to  identify  and  evaluate  existing  design 
strengths  and  weaknesses. 

Other  organizations  may  choose  to  skip  the  modeling  of  the 
existing  process  to  focus  attention  directly  on  alternatives  for  new 
process  design. 

Those  organizations  which  have  progressively  utilized  process 
models  may  have  graduated  to  the  use  of  static  and  dynamic 
models  to  further  characterize  and  simulate  process  activities. 

Process  modeling  is  addressed  more  thoroughly  in  Section  4.3  of 
this  document. 

Many  tools  and  techniques  are  available  for  analyzing  and 
evaluating  processes.  Evaluation  may  be  necessary  to  examine  the 
existing  process  as  well  as  a  new  design  alternative.  As  part  of 
process  evaluation,  organizations  will  often  combine 
benchmarking  and  simulation  in  the  form  of  static  or  dynamic 
models  to  examine  both  "as-is"  and  "to-be"  process  designs. 
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New  process  designs  which  are  found  to  be  workable  are  then 
carried  into  the  transformation  stage,  while  those  with 
unacceptable  weaknesses  are  modified  through  redesign. 

Process  evaluation  is  addressed  more  thoroughly  in  Section  4.4  of 
this  document. 


Process  Redesign 


As  part  of  process  redesign,  business  constraints  such  as  time, 
financial  resources,  and  human  factors  are  integrated  with  enabling 
technologies  to  achieve  optimum  workflow  for  process  and 
product  value.  In  reality,  redesign  and  evaluation  may  occur  almost 
simultaneously  by  quickly  adjusting  proposed  designs  and 
reviewing  potential  business  impacts. 

Process  redesign  is  addressed  more  thoroughly  in  Section  4.5  of 
this  document. 
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At  this  point  of  BPR,  the  stage  is  set  to  begin  thinking  of  the 
future.  During  this  step,  it  is  essential  to  examine  which  of  the 
business  goals  and  targets  are  impacted  by  the  business  process 
under  review  and  ensure  that  the  features  desired  of  the  business 
process  will  result  in  removal  of  business  process  health  problems. 

Visioning,  sometimes  referred  to  as  imagineering  is  the  step  by 
which  an  ideal  business  process  is  described  without  respect  to 
technology,  constraints,  or  implementation  strategy.  An  effective 
process  vision  provides  direction  to  process  changes.  Burt  Nanus, 
in  his  book  "  Visionary  Leadership"  states  that: 

the  right  vision  is  an  idea  so  energizing  that  it  in  effect 
jump-starts  the  future  by  calling  forth  the  skills g 
talents,  and  resources  to  make  it  happen 

Once  an  ideal  business  process  vision  is  established,  the  vision 
may  not  require  change  unless  the  core  of  the  business  process 
purpose  has  changed,  or  the  ability  of  the  team  to  imagine  has 
increased  (it  is  difficult  to  imagine  what  we  don't  understand). 

4.2.1.  IDENTIFY  NEW  PROCESS  FEATURES 

Initial  efforts  to  construct  a  process  vision  should  be  focused  on 
identifying  desired  process  features.  Features  may  be  quickly 
identified  by  asking  the  following  question: 

In  the  best  of  worlds,  how  would  the  process  operate? 

Creating  a  process  vision  requires  the  input  of  the  most  creative 
team  members.  Those  directly  involved  in  the  process  may  be  less 
creative  due  to  their  pride  of  ownership  in  the  current  process 
design.  In  order  to  stimulate  initial  ideas  and  concepts,  teams  must 
utilize  proven  methods  which  encourage  creativity,  com¬ 
munication,  while  maintaining  a  structured  team  environment. 

Brainstorming  Methods  such  as  brainstorming  can  be  of  particular  use  when 

constructing  a  process  vision.  Brainstorming  is  a  common 


Establish  Ideal  Business 
Process  Vision 
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Record  Process  Vision 


Process  Vision  Example 


approach  used  for  generating  ideas.  Commonly,  a  session  begins 
with  a  team  leader  identifying  the  topic  or  writing  a  question  of 
interest  for  team  action.  The  goal  is  to  generate  as  many  ideas  as 
possible,  in  the  shortest  possible  time.  Ideas  are  not  evaluated  until 
an  exhaustive  list  of  ideas  is  completed.  This  exercise  generally 
takes  approximately  15  minutes.  Once  no  other  ideas  are  presented 
by  team  members,  each  idea  is  discussed  and  evaluated  with 
respect  to  the  desired  goals  established. 

The  Nominal  Group  Technique  (NGT)  is  a  natural  way  of 
prioritizing  a  list  of  ideas.  A  brief  overview  of  NGT  results  in  the 
following  basic  approach: 

1.  Remove  redundant  ideas/features.  Many  times,  several 
ideas  are  presented  which  are  redundant.  Removal  of  these 
ideas  will  streamline  ranking  activities. 

2.  Each  team  member  scores  each  idea/features  using  numbers 
from  one  to  X,  where  X  is  the  total  number  of  ideas/features. 
This  results  in  a  ranked  list  of  entries  created  by  each  team 
member. 

3.  Integrate  team  member  scores  by  adding  the  scores 
provided  by  each  team  member  for  each  idea/feature 
together. 

As  a  result,  the  ideas/features  with  the  highest  numbers  represent 
the  most  important,  or  highest  value  ideas.  The  more  important 
features  can  then  be  incorporated  into  the  process  vision. 

The  resulting  features  should  be  documented  in  a  process  feature 
list,  which  forms  the  foundation  of  a  process  vision.  Features 
should  be  listed  in  a  sequential  order  (i.e.  the  order  in  which  they 
would  occur  within  the  process)  and/or  priority  order  (if  features 
are  not  sequence  dependent  but  may  be  classified  by  importance). 
Each  process  vision  should  be  included  as  part  of  the  Process 
Management  Notebook  (PMN). 

Figure  4.2-1  presents  a  simplified  example  of  a  process  vision  for  a 
customer  response  process. 
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The  customer  response  process  for  company  X 
will  exibit  the  following  features: 

•  customers  will  have  immediate  access  to  the 

business  enterprise,  without  delay,  to  report 
problems  of  importance 

•  staff  will  be  able  to  quickly  select  and  record 
problems  reported  by  customers 

•  staff  will  be  able  to  categorize  and 

immediately  route  problems  to  an  available 
service  representative 

•  service  representatives  will  provide  high 

quality  technical  support  to  customers  with 
information  from  all  past  service  calls  at  their 
fingertips 

•  management  will  have  continuous,  automatic 

feedback  on  all  levels  of  customer  responses 
allowing  for  quick  identification  of  high 
volume  problems 

. •  •  •  etc. 

. •  •  •  etc. 


Figure  4.2-1.  Process  Vision  Example 

As  a  general  rule,  a  process  vision  should  be  quick  to  establish  and 
difficult  to  argue  with.  Since  there  are  few,  if  any,  constraints,  the 
vision  simply  represents  characteristics  of  the  best  possible 
process. 

4.2.2.  Align  New  Features  with  Business  Goals  and  Targets 

Once  a  process  feature  list  is  established,  each  of  the  features 
should  be  reviewed  to  ensure  consistency  with  business  goals  and 
targets.  As  a  test,  ask  the  following  question: 

If  the  process  achieved  the  desired  feature ,  would 
progress  be  made  towards  business  goals? 

If  the  answer  is  "no",  then  the  feature  may  be  less  important  to  the 
vision  and  should  be  noted  as  such.  Review  of  features  will  often 
show  weaknesses  in  business  goals  and/or  targets.  If  goals  require 
modification,  then  update  goals  within  the  business  mission 
statement,  as  discussed  in  Chapter  2. 
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4.2.3.  IDEAL  PROCESS  MODELING 

Some  analysts  will  extend  the  concept  of  a  process  vision  to  form 
an  ideal  process  model.  An  ideal  process  model  is  formed  by 
adapting  features  outlined  as  part  of  the  process  vision  into 
activities  required  for  process  completion.  Such  a  model  may  then 
be  used  as  a  basis  for  redesign  activities,  and  represents  a  form  of 
an  internally  created  process  benchmark. 

4.2.4.  ESTABLISH  MEASURABLE  PROCESS  GOALS/TARGETS 

The  goals  and  targets  established  for  the  business  mission  may  or 
may  not  directly  relate  to  the  business  process  under  study.  If  the 
business  goals  and  process  goals  are  not  directly  aligned,  then  a 
separate  set  of  process  goals/targets  should  be  established. 

Process  goals/targets  should  be  established  using  the  same  rules 
outlined  for  business  level  elements  in  Chapter  2,  but  should  focus 
attention  on  process  boundaries.  For  example,  if  a  business  goal  is 
to  increase  net  profit  by  10%,  the  an  associated  process  goal  may 
be  to  reduce  production  cost  by  10%  or  increase  sales  volume  by 
10%.  Several  process  goals  may  be  required  in  order  to 
successfully  meet  a  single  business  goal. 

Goals  associated  with  each  process  should  be  recorded  within  the 
Process  Management  Notebook. 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


Page  82 


CHAPTER  4.  INNOVATION  &  REDESIGN 


4.3.  MODEI-  PROCESSES 

Some  organizations  may  have  detailed  documentation  available  on 
the  existing  system  design,  or  potentially  have  an  existing  process 
model.  If  an  existing  process  model  exists,  then  use  the  contents  of 
this  section  to  verify  the  model  integrity. 

A  process  model  can  be  generated  using  automated  tools  or  by 
manual  means.  The  authors  suggest  the  use  of  automated  process 
models  to  support  effective  maintenance  of  an  overall  business 
enterprise  model  and  to  support  later  analysis  and  simulation 
activities. 

Characteristics  of  automated  modeling  toolkits  are  described  in 
4.3.2  through  4.3.4  of  this  chapter;  these  relate  to  the  construction 
of  activity,  throughput,  and  operational  models. 

4.3.1.  Process  Modeling  Overview 

At  this  point  in  the  reengineering  process,  the  following  statements 
should  be  true: 

•  a  set  of  processes  has  been  identified  and  defined 

•  initial  inputs  and  outputs  have  been  developed  portraying  the 
major  streams  of  information  and/or  workflow  required  by 
each  business  process 

•  the  health  and  impact  of  each  business  process  to  the  overall 
business  value  stream  has  been  assessed  and  recorded, 
establishing  which  business  processes  will  be  reengineered 

To  develop  a  deeper  level  of  understanding  of  a  business  process, 
one  must  identify  the  activities  which  constitute  the  inner  workings 
of  a  business  process.  This  activity  set  represents  the  essence  of 
how  business  inputs  are  transformed  into  business  outputs  in  a 
value  added  manner. 


4.3.1. 1.  Process  Maturity 

The  maturity  of  a  business  process  within  the  organization  will 
determine  the  nature  of  innovation  and  transformation  required  to 
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achieve  process  improvements.  In  his  book  entitled  "Business 
Systems  Engineering" ,  Gregory  Watson  describes  the  quality 
improvement  levels  of  a  process  by  utilizing  a  diagram  similar  to 
that  shown  in  Figure  4.3-1. 


Time  - 

Figure  4.3-1.  Process  Quality  Improvement  Levels 


Each  of  these  quality  levels  can  be  thought  of  as  levels  of  process 
maturity.  The  greater  the  knowledge  of  a  business  process,  the 
more  rigorous  the  analysis  which  can  be  performed  to  improve  the 
process.  To  determine  the  maturity  level  of  the  current  process,  ask 
the  following  questions: 

•  Is  there  a  clear  understanding  of  the  existing  process  and  the 
need  to  change? 

•  Does  the  organization  have  a  common  vision  for  the 
process? 

•  Is  the  process  well  documented  or  modeled  to  a  degree 
which  eliminates  confusion  in  the  discussion  of  process 
activities? 

•  Is  the  process  simplified  to  a  level  where  common  causes  of 
poor  process  quality  (such  as  scrap  and  rework)  have  been 
identified? 

•  Is  the  process  nearly  meeting  goals,  requiring  either 
reduction  in  process  variability  or  complete  breakthrough  to 
improve  process  efficiency? 
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4.3.I.2.  Process  Anatomy 

In  previous  chapters,  the  topic  of  business  anatomy  was  discussed 
to  describe  how  elements  of  a  business  process  can  traverse 
organizational  boundaries,  and  to  illustrate  the  interdependence  of 
business  processes.  Understanding  the  physical  nature  of  a 
business  process  is  also  necessary  prior  to  deciding  on  a  new 
process  design. 

Architecture  Layers  Each  business  process  is  constructed  of  several  distinct  layers, 

including  the  physical  environment,  people,  automation,  and  data 
as  illustrated  in  Figure  4.3-2. 


Figure  4.3-2.  Business  Process  Architecture  Layers 


•  Physical  Environment  -  The  process  physical  environment 
includes  all  of  the  physical  objects  utilized  as  part  of  the 
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process  design.  Examples  of  physical  objects  include  filing 
cabinets,  postage  machines,  facilities,  and  books.  Physical 
objects  can  also  include  hardware  which  is  operated  through 
automation,  such  as  automated  process  control  systems. 

•  People  -  People  perform  the  manual  tasks  associated  with  a 
business  process.  Even  in  highly  automated  systems,  people 
are  required  to  evaluate  and  interpret  system  processing 
results,  coordinate  processing  functions,  and  coordinate 
approvals.  Technology  is  gradually  narrowing  the  gap 
between  automation  and  the  physical  environment, 
providing  new  ways  for  entry  and  summarization  of 
information  without  human  intervention. 

•  Automation  -  Automation  implies  the  execution  of  process 
activities  using  software.  Automation  can  take  many  forms, 
from  software  which  allows  for  entry,  review,  and  storage  of 
vital  business  information  to  software  used  to  monitor  and 
control  the  activities  of  an  automated  packing  system.  The 
interface  between  people  and  the  software  system,  or 
between  people  and  a  combination  of  hardware/software,  is 
often  referred  to  as  the  man/machine  interface. 

•  Data  -  Data  are  the  lifeblood  of  a  business  process.  For  the 
purpose  of  this  document,  the  term  data  will  be  used  loosely 
to  include  all  forms  of  information,  whether  it  is  stored  in  a 
computer,  filing  cabinet,  or  the  mind  of  an  employee.  Data 
in  one  form  or  another  can  be  used  to  determine  the  status  of 
a  process,  the  results  of  a  past  process,  and  the  steps  required 
to  complete  an  existing  process.  In  summarized  form,  data 
contributes  to  understanding  customers,  trends,  and 
operational  inefficiencies.  In  short,  accurate  and  timely  data 
are  the  foundation  of  a  business  process. 

The  progression  of  activity  through  the  process  architecture  layers 
is  referred  to  as  process  workflow. 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


Page  86 


CHAPTER  4.  INNOVATION  &  REDESIGN 


4.3.I.3.  Process  Model  Types 

The  concept  and  resulting  approaches  for  developing  an  overview 
of  the  process  workflow  for  representation  and  analysis  is  called 
process  modeling.  Several  types  of  models  exist,  including: 

•  activity  model  -  graphically  identifies  the  work  activities  that 
constitute  the  business  process 

•  throughput  (static  model)  -  analyzes  and  records  activity 
time  and  priority  impact  of  the  activities  for  root-cause 
analysis 

•  operational  (dynamic  model)  -  analyzes  important  process 
variables  as  they  vary  with  time,  as  if  the  system  was 
actually  operating,  based  on  a  designated  operational 
scenario 

The  use  and  application  of  such  models  are  largely  dependent  on 
the  current  process  maturity  within  the  business  enterprise  and  the 
availability/use  of  automated  modeling  tools.  Since  each  of  the 
models  requires  progressively  more  information  relating  to  a 
process,  only  mature  processes  will  be  candidates  for  the  use  of 
more  complex  models.  Further  detail  on  the  use  of  model  types  is 
provided  in  the  following  subsections. 

Are  there  existing  In  addition  to  process  maturity,  teams  review  the  existence  and 

process  models?  .  .  ,  ,  , 

maturity  of  existing  models  using  the  approach  illustrated  in  Figure 

4.3-3.  As  this  figure  shows,  the  use  of  more  progressive  models 

requires  that  previous  models  exist  and  are  considered  valid. 
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Figure  4.3-3.  Process  Model  Review 


Determining  whether  a  given  model  type  is  essential  for  process 
improvement  requires  a  greater  understanding  of  the  model  types 
and  associated  automated  modeling  toolkit  characteristics,  as 
provided  in  the  following  subsections.  Within  this  section,  the 
word  toolkit  is  used  to  described  a  set  of  automated  functions 
supporting  process  modeling  tasks. 
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Record  Process  Models 


Process  models  are  a  form  of  process  documentation  within 
themselves.  Each  type  of  model  provides  further  understanding  of 
the  process  to  analysts.  Regardless  of  the  type  of  model  selected  or 
the  level  of  modeling  performed,  the  resulting  process  models  must 
be  effectively  recorded  for  future  reference  in  the  Process 
Management  Notebook. 


4.3.2.  Activity  Modeling 


Working  in  close  cooperation  with  the  members  of  the  business 
process  and  the  business  enterprise  reengineering  team,  a  process 
analyst  develops  the  sequence  of  activities  accomplished  by  the 
business  process.  An  activity  model  is  essential  for  effective 
process  documentation,  whether  the  model  is  documented 
manually  or  through  the  use  of  automated  toolkits. 


4.3.2.I.  Activity  Model  Construction 

An  activity  model  represents  the  next  level  of  decomposition  of  a 
process  model.  A  processing  activity  is  similar  to  a  business 
process  in  definition,  but  may  integrate  vertical  (organizational), 
horizontal  (staffing  levels),  and  physical  (process  anatomy) 
attributes  within  a  business.  As  part  of  process  anatomy,  activity 
models  form  a  foundation  for  separating  manual  activities  from 
automated  activities.  As  a  guideline,  a  new  activity  is  formed  every 
time  one  of  the  following  conditions  occurs: 

1 .  the  content  of  the  work  package  is  changed  (value  is  added) 

2.  workflow  changes  organizations 

3.  responsibility  is  passed  to  a  different  level  within  the 
organization  (staff  to  staff  hand-offs  or  transfer  of 
responsibility  to  management) 

4.  the  workflow  crosses  boundaries  of  physical  process 
anatomy  (manual  activity  vs.  automated  activity). 

An  ideal  process  vision  (discussed  in  the  Section  4.2)  is  not 
concerned  with  Items  2  through  4,  since  physical  design  concerns 
such  as  technology,  staff  levels  and  organizational  boundaries  were 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


CHAPTER  4.  INNOVATION  &  REDESIGN 


Page  89 


intentionally  excluded.  Therefore,  the  activity  model  represents  the 
first  physical  model  of  the  existing  process.  Figure  4.3-4  provides  a 
limited  example  of  an  activity  model  with  activities  listed  along  the 
top  in  a  left  to  right  fashion.  Notice  that  this  particular  example 
shows  the  triggering  customer  event  as  part  of  the  activity  model. 


Event  Tracking  and 
Process  Walkthroughs 


Simplified  examples  of  both  "as-is"  and  "to-be"  CSK  activity 
models  are  provided  in  sections  4.5. 3. 2  and  4.5. 3. 3  respectively  of 
this  document. 

Event  tracking  is  commonly  used  as  an  approach  to  process 
modeling.  The  basic  principles  of  event  tracking  involve  following 
the  flow  of  a  process  from  an  initial  input  (stimulus)  to  a 
designated  output  (response).  Others  may  refer  to  this  strategy  as  a 
process  walkthrough. 

For  large  processes  (those  which  encompass  many  locations, 
levels,  and/or  organizational  units),  event  tracking  may  be  too  time 
consuming  for  practical  application.  In  such  cases,  the  business  can 
construct  small  activity  models  for  each  organizational  unit  and 
hook  the  models  together  to  form  a  complete  process  model. 
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4.3.2.2.  Activity  Model  Toolkit  Characteristics 

A  mechanism  for  collecting  and  recording  information  relating  to 
process  activities  falls  within  the  domain  of  business  process 
analysis  work  tools  or  toolkits.  The  use  of  a  computerized  tool  or 
set  of  tools  allows  process  analysts  to  more  efficiently  capture  and 
record  data  about  the  activities  of  a  business  process,  such  that 
subsequent  analysis  and  synthesis  can  be  performed  to  establish 
whether  the  present  or  newly  designed  process  meets  the  goals  and 
targets  of  the  business. 

Standard  Modeling  The  capability  of  a  graphical  tool  to  diagram  the  activities  that 

Conventions  ,  _  „  ,  . 

comprise  the  workflow  of  a  business  process  can  reside  in  a 

separate  toolkit,  or  can  be  integrated  with  the  throughput  and/or 

operational  modeling  toolkit.  Whether  separate  or  integrated,  an 

activity  modeling  toolkit  must  encompass  a  library  of  symbols 

which  explicitly  describe  the  possible  activities  accomplished 

within  a  business  process. 

Some  of  the  common  symbol  sets  used  for  modeling  activities  of  a 
business  process  are: 

•  ANSI  Information  Processing  Symbols,  ANSI  X3. 5-1970 
and  ANSI  5807- 1985(E) 

•  DIN  Information  Processing  Standard 

•  ISO  5807  Flowchart  Symbols 

•  SADT/IDEFO  -  Structured  Analysis  and  Design 
Technique/ICAM  Definition  Method 

The  simplest  form  of  flowcharting  utilizes  the  ANSI  symbol  set  as 
shown  in  Figure  4.3-4.  Many  times,  symbol  sets  are  customized  to 
meet  the  needs  of  specific  customers.  Figure  4.3-5  represents  a 
customized  symbol  set  developed  and  used  by  KPMG  Peat 
Marwick  Co.  and  presented  in  the  book  entitled  " The  Art  of 
Business  Process  Management" . 
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Figure  4.3-5.  ANSI  Symbols  for  Process  Diagram 


Symbol 


3.5  Man  Month  2.5  Weeks 


Ongoing  Activity  -  Indicates  an  activity  that  does  not  have  a 
discrete  beginning  and  ending  point.  There  are  generally 
support  activities  or  level-of-effort  work. 


Personal  Knowledge  -  Documents  those  areas  of  the  work 
process,  activities  or  decision  points  where  the  knowledge 
required  to  carry  out  the  activity  or  make  the  decision  is  not 
documented  in  policies  or  procedures.  This  helps  identify  risk 
areas  in  the  process. 


Activity  Resource  Documentation  -  This  expanded  form  of  the 
activity  symbol  documents  the  resources  utilized  in  the  activity 
such  as  manpower,  time,  and  dollars. 


Activity  Lag  Time  -  The  notation  between  symbols  documents 


■ . .  2.5  Days  . .  i  Avcuvny  i^ag  lime  -  ine  notation  Dei  ween  symoois  uocumei 

K- — “W  I  the  time  between  activity  completion  and  the  initiation  of  a 

subsequent  activity. 


Parallel  or  Multiple  Activity/Decision  -  Illustrates  the  multiple 
or  simultaneous  execution  of  the  same  activity  or  decision. 


Secondary  Organization  -  Documents  the  involvement  of  an 
organization  that  has  a  minor  role.  This  is  used  to  save  space  in 
the  overall  diagram  and  is  placed  directly  in  line  of  activity 
flow. 


Data  Store/System  Support  -  Indicates  an  automated  system  or 
database  used  to  support  an  activity  or  decision. 


Subprocess  -  Indicates  that  a  detailed  subprocess  exists  to 
support  the  execution  of  the  activity  but  will  not  be  detailed  at 
this  time. 


Figure  4.3-6.  Customized  Symbol  Set  -  KPMG  Peat  Marwick  Co. 
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Activity  Model  Toolkit 
Characteristics 


There  are  hundreds  of  process  modeling  tools  and  hundreds  of 
characteristics  associated  with  each  tool.  It  is  not  the  intent  of  this 
document  to  provide  the  reader  with  a  detailed  description  of  tools, 
but  rather  to  establish  a  cursory  frame  of  reference  as  to  what 
should  be  considered  in  the  selection  of  modeling  tools. 

The  minimum  characteristics  common  to  modeling  toolkits  include 
the  following: 


An  object  based  drag-and-drop  symbol  capability  composed 
of  a  symbol  library  -  Allows  the  analyst  to  build  the  process 
flow  diagram  with  a  What  You  See  Is  What  You  Get 
(WYSIWYG)  capability  by  selecting  from  an  on-screen 
palette  of  symbols  used  to  describe  activities  for  the  process 
under  study. 


•  Horizontal  and  vertical  line  sectioning  -  Allows  the  analyst 
to  partition  or  grid  the  diagram  vertically  and/or  horizontally 
to  depict  transition  boundaries  between  organizational  units 
and  key  levels  within  the  process  anatomy/architecture.  Such 
capability  will  also  allow  for  identification  of  staff 
responsibilities  for  activities  as  necessary  (i.e.  manager, 
supervisor,  engineer,  etc.) 


/mbol  block  naming  capability  with  dialog  box  for 


primitive  data  entry  -  Allows  the  analyst  to  record  the  name 
of  each  activity  within  the  business  process  and  store 
primitive  data  relating  to  the  activity  for  later  use  in 
throughput  and/or  operational  models. 


•  Process  diagram  hierarchy  linking  capability  -  Allows  the 
analyst  to  link  process  models  together  or  create  a  hierarchy 
of  activity  models  to  simplify  model  use  and  readability. 


A  list  of  process  modeling  and  analysis  tools  identified  during  the 
creation  of  this  document  is  provided  in  Appendix  A.3. 
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4.3.3.  Throughput  Modeling 

Once  an  activity  model  has  been  established  for  a  given  process, 
the  process  analyst  in  cooperation  with  those  involved  with  the 
process  can  begin  to  develop  a  throughput  model. 

A  throughput  model  can  be  useful  to  identify  characteristics  of  an 
existing  "as-is"  model,  or  in  the  review  of  a  "to-be"  process 
alternative. 

4.3.3. 1.  Throughput  (Static)  Model  Construction 

A  throughput  model  facilitates  the  creation  of  snapshot  views  of 
the  business  process  to  be  analyzed  from  a  variety  of  perspectives. 
The  primary  goal  is  to  ascertain  root-causes  of  unsatisfactory 
process  flow  characteristics.  In  other  words,  the  goal  of  the 
throughput  model  is  to  identify  value  adding  and  non-value  adding 
activity  characteristics. 

"Actual Reality"  It  js  common  that  the  initial  activity  models  created  constitute  a 

somewhat  hazy  view  of  the  "as-is"  business  process.  Team 
members  and  process  workers  may  find  it  difficult  to  agree  on  "as- 
is"  process  characteristics  due  to  the  variety  of  perspectives  and 
distractions  associated  with  ideal  features  and  "to-be"  models 
under  consideration.  This  collaboration  often  yields  a  throughput 
model  with  a  combination  of  characteristics  derived  from  "as-is" 
and  "to-be"  business  processes. 

4.3.3.2.  Throughput  (Static)  Model  Toolkit  Characteristics 

A  throughput  modeling  toolkit  utilizes  a  primitive  data  set  (i.e. 
name,  location,  time,  skill  level,  and  impact)  recorded  for  each 
activity  in  the  process  model.  The  modeler  enhances  this 
information  with  additional  data  for  higher  level  categories 
concerned  with  labor,  quality,  root-cause,  capacity,  and  workload. 
Although  the  specific  data  entries  for  these  categories  differs 
depending  on  the  throughput  modeling  tool  selected,  the  primitive 
data  elements  are  common  to  all  toolkits.  A  further  look  at  the 
primitive  data  set  may  provide  better  insight  into  the  use  of  a 
throughput  model. 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


Page  94 


CHAPTER  4.  INNOVATION  &  REDESIGN 


•  Name  -  Specifies  a  name  associated  with  the  activity. 

•  Location  -  Identifies  the  physical  place  the  activity  is 
accomplished. 

•  Time  -  Relates  to  the  duration  assigned  to  a  given  activity  or 
the  value  of  process  time  for  completion. 

•  Skill  Level  -  Identifies  the  grade  of  staff  completing  work 

•  Impact  -  Represents  an  assigned  importance  level  to  the 
activity  with  respect  to  completion  of  the  business  process 
cycle. 

The  primitive  data  elements  are  measures  from  which  these  higher 
order  metrics  such  as  cost,  labor,  and  cycle  time  are  derived. 

The  metrics  generated  by  the  throughput  model  comprise  the 
determination  of  quality  characteristics  associated  with  each 
activity  and  the  overall  process.  Throughput  modeling  tools 
typically  utilize  grid-like  spreadsheets  to  display  process  activities 
down  the  leftmost  column  along  with  associated  measures/metrics 
in  the  horizontally  adjoining  cells.  Such  metrics  are  often 
supplemented  with  more  complex  analytical  tools  to  further 
investigate  process  quality. 

Chapter  5  provides  an  overview  of  common  analytical  tools 
supporting  measurement  and  analysis  of  process  activities  which 
may  be  included  within  modeling  toolkits. 


4.3.4.  OPERATIONAL  (DYNAMIC)  MODELING 

Dynamic  models  are  most  commonly  used  in  the  assessment  of 
"to-be"  process  alternatives.  Therefore,  the  reader  may  wish  to 
return  to  this  section  after  reviewing  sections  relating  to  process 
redesign  (Section  4.5).  Dynamic  models  provide  a  means  by  which 
several  operational  models  (potential  designs)  may  be  created,  and 
selectively  compared,  using  "what-if"  scenarios.  Using  such 
models,  the  analyst  can  trade-off  design  characteristics  until  a 
desired  solution  is  reached. 
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Once  a  design  exhibits  satisfactory  performance,  dynamic 
modeling  tools  may  also  be  used  to  execute  dynamic  simulations 
of  the  "as-is"  and  "to-be"  process  cycles.  As  a  minimum,  dynamic 
simulation  provides  further  insight  into: 

•  potential  costs  and  production  gains  over  time 

•  loading  factors  of  designs  which  may  reduce  or  increase  risk 
of  successful  implementation 

•  causes  and  effects  of  transient  conditions,  not  readily  visible 
within  standard  activity  and  throughput  models 

Historically,  dynamic  modeling  has  been  more  commonly  used  in 
manufacturing  and  production  related  processes  where  process 
activities  are  well  defined.  More  recently,  dynamic  modeling  is 
playing  an  increasing  role  in  determining  the  impact  of  changing 
worker  skill  levels,  insertion  of  automation,  and  reorganization  of 
activities  within  office  environments. 

Dynamic  modeling  is  not  for  every  business  enterprise  and  often 
requires  the  investment  of  significant  time  and  effort.  The  authors 
recommend  the  use  of  dynamic  modeling  to  analyze: 

•  large  or  complex  businesses  processes 

•  critical  processes  with  a  high  risk  of  failure 

•  novel  designs,  where  innovations  warrant  investment 

4.3.4.I.  Operational  (Dynamic)  Model  Construction 

Little  or  no  physical  construction  actions  are  required  for  dynamic 
modeling.  Generally,  the  throughput  model  is  used  to  establish 
operational  conditions  which  then  may  be  used  as  input  "starting 
points"  for  dynamic  modeling  efforts.  Therefore,  dynamic 
modeling  efforts  assume  the  existence  of  a  valid  throughput  model 
and  resulting  static  metrics.  If  operating  conditions  are  not 
available  for  a  dynamic  investigation  from  the  static  modeling 
effort,  then  such  conditions  must  be  established  prior  to 
continuation. 
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4.3.4.2.  Operational  (Dynamic)  Model  Toolkit  Characteristics 

A  dynamic  simulation  toolkit  is  similar  to  the  visual  design  tool 
utilized  in  the  activity  model  toolkit  (i.e.  object  based  drag-and 
drop,  pallet  based  symbol  library,  diagram  hierarchy  linking,  etc.). 
The  graphical  layout  of  the  dynamic  model  emulates  the  activity 
sequence  of  the  activity  model  using  dynamic  modeling  symbol 
blocks.  Dynamic  modeling  symbol  blocks  represent  functions  such 
as  a  queue,  a  transaction,  a  decision  or  a  storage  block.  In  addition, 
the  model  utilizes  parameters  relating  to  starting  conditions 
(collected  from  the  throughput  model)  for  the  simulation,  which 
initiates  the  mathematical  calculations  of  the  discrete  equations. 

For  a  steady-state  definition  of  either  an  "as-is"  or  "to-be"  process 
cycle,  the  symbol  blocks  of  the  dynamic  toolkit  are  chained 
together  following  the  flow  of  the  associated  activity  model. 
Condition  data  is  then  entered  into  the  blocks  from  the 
corresponding  throughput  model,  and  the  model  is  run  to  steady- 
state  for  a  predetermined  time  to  verify  conformance  with  the 
throughput  model.  Once  steady-state  throughput  is  verified,  the 
operational  conditions  and  transients  are  exercised  using  the 
dynamic  model  with  outputs  generated  and  analyzed. 
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4.4.  Evaluate  Process 

For  the  purposes  of  this  document,  process  evaluation  is  discussed 
with  respect  to  two  distinct  scenarios: 

1.  reviewing  an  existing  process  ("as-is") 

2.  reviewing  a  potential  new  process  design  ("to-be") 


Iteration  of  New  Process 
Designs 


The  ideas  and  strategies  discussed  within  this  section  can  be 
applied  to  both  "as-is"  and  "to-be"  process  evaluations. 

To  be  most  effective,  process  evaluation  and  process  redesign 
should  be  tightly  integrated  and  extensively  iterative.  Each  time  a 
change  is  made  to  a  "to-be"  process  design,  the  alternative  process 
should  be  evaluated.  The  greater  the  number  of  changes  made  to  a 
process  prior  to  evaluation,  the  greater  the  potential  of  inducing 
problems  without  known  impacts.  Therefore,  once  process  models 
reach  a  well  documented  state  of  maturity,  the  authors  recommend 
iterative  evaluation  upon  changes  to  process  designs  (as  illustrated 
in  Figure  4.4-1).  Iteration  should  continue  until  the  "to-be"  process 
design  meets  desired  business  goals/targets. 


Figure  4.4-1.  Design  -  Evaluation  Iteration 


4.4.1.  THE  SEARCH  FOR  PROBLEMS  AND  OPPORTUNITIES 

Effective  process  analysis  involves  the  use  of  modeling,  metrics, 
and  most  of  all,  common  sense.  Prior  to  embarking  on  a  detailed 
analysis,  a  broader  understanding  of  common  concepts  and  issues 
should  be  considered. 
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Is  there  a  Process 
Problem  or  Opportunity? 


Opportunity-Driven 

Change 


Concise,  Precise 
Definition 


Decompose  If  Necessary 


Errors  of  Depth 


Process  Interfaces 


A  problem,  with  its  negative  connotation,  is  an  inability  of  a 
business  process  to  meet  performance  requirements,  goals,  or 
targets.  Problems  may  be  quantitative  (inadequate  production 
volume)  or  qualitative  (unacceptable  variations  in  perceptions  of 
quality).  A  description  of  a  problem  is  incomplete  without  a 
precise  statement  of  the  applicable  business  goal  or  target  which 
has  not  been  met. 

An  opportunity  is  a  chance  to  improve  performance  over  current 
levels,  or  to  excel.  An  opportunity  is  proactive;  the  proposed 
development  must  stand  on  its  own  merits  as  a  cost-effective 
proposal.  Conversely,  problems  are  generally  dealt  with  reactively, 
and  tend  to  create  their  own  priority. 

A  concise,  precise  definition  of  the  problem  or  new  opportunity 
must  be  stated.  This  definition  should  reflect  the  problem 
decomposition  completed  during  process  assessment  or  analysis, 
insuring  that  the  problem,  and  not  a  symptom,  is  described. 

Note  that  initial  process  health  as  identified  in  Chapter  3  may 
identify  a  myriad  of  symptoms  but  may  not  point  to  the  root 
problem  area.  Decomposition  of  the  business  process  should  be 
iterated  at  this  point  to  refine  the  underlying  causes  for  the 
particular  problem  reflected  by  the  initial  symptoms. 

The  most  common  mistakes  at  this  stage  are  errors  of  depth. 
Typically,  the  problem  is  either  over-  or  under-defined.  Failure  to 
adequately  understand  and  state  the  problem  and  conditions  may 
mean  that  analysts,  designers,  and  implementers  attack  the  wrong 
problem.  Defining  the  problem  in  excruciating  detail  can  bog  down 
a  project,  perpetuate  mistaken  assumptions,  and  constrain 
designers  from  applying  creative  solutions. 

Processes  may  interact  closely  with  adjacent  activities  of  other 
business  processes.  It  may  be  prudent  in  such  a  case  to  explicitly 
set  an  analysis  boundary  larger  than  the  target  process.  As  a 
minimum,  inputs  and  outputs  associated  with  activities  from  other 
processes  should  be  clearly  understood. 
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4.4.2.  ADDING  VALUE 

Value  is  the  cornerstone  of  any  business  enterprise.  There  are  two 
basic  types  of  value:  customer-perceived  value  and  process  value. 
While  BPR  tends  to  focus  on  the  process  aspects  of  a  business 
enterprise,  the  impact  of  customer  perception  must  not  be 
underestimated. 

4.4.2. 1.  Customer-Perceived  Value 

There  are  few  businesses,  consultants,  or  customers  who  do  not 
generally  understand  what  customers  really  want: 

•  high  quality  products  and  services 

•  lowest  cost  available  per  the  quality  of  product 

•  few  or  no  delays  in  receiving  desired  services 

The  "trick"  is  in  understanding  how  to  saturate  the  business 
enterprise  with  the  "voice  of  the  customer"  and  improve  customer 
perceptions.  The  fact  is  that  any  change  to  a  business  process 
which  improves  customer  perceptions  while  maintaining  existing 
process  efficiency  adds  value.  Customer  perceptions  can  be 
changed  in  a  variety  of  manners.  Automakers,  such  as  Ford  Motor 
Company,  recently  improved  customer  perceptions  by  bringing 
innovative  new  designs  to  the  market  quicker.  Ford  is  now  able  to 
conceive,  design  and  build  new  car  models  in  two  to  three  years 
versus  previous  cycle  times  of  over  four  years.  Getting  new  car 
designs  to  market  prior  to  competitors  has  changed  customer 
perceptions  and  led  to  increased  profits  for  Ford  during  recent 
years. 

Customer-Perceptions  All  changes  in  a  company's  sales  volume  are  directly  impacted  by 
Are  Communicable 

customer  perceptions  of  the  company's  products  and  services.  A 
study  conducted  for  the  White  House  Office  of  Consumer  Affairs 
indicates  that  the  average  customer  who  has  a  problem  with  an 
organization  tells  nine  or  ten  people  about  it.  Thirteen  percent  of 
people  who  have  a  problem  with  an  organization  recount  the 
incident  to  more  than  twenty  people.  Taking  advantage  of  the 
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Product  Oriented 
Categories 


4. 4.2.2.  Process  Value 


infectious  nature  of  customer  perceptions  (either  negative  or 
positive)  can  vault  a  company  past  competitors. 

Customer-perceived  value  is  generally  product  oriented  and  can 
commonly  be  categorized  according  to  the  following: 

•  Function  -  Products  and  services  must  be  considered  reliable 
and  meet  the  intended  need  of  the  customer 

•  Response  -  Products  and  services  must  be  made  available  to 
customers  in  a  timely  manner 

•  Features  -  Products  and  services  may  provide  extended 
features  and  attributes  which  enhance  customer  satisfaction 
and  discriminate  the  product  from  others  in  the  market  place 

•  Cost  -  Price  of  products  and  services  must  be  acceptable 
with  respect  to  quality  (function/features)  and  the  cost  of 
similar  competitor  products 

As  existing  processes  are  evaluated  or  new  designs  are  constructed, 
care  should  be  taken  to  influence  customer-perceived  values  in  a 
positive  manner. 


Process  value  directly  contributes  to  customer-perceived  value  in 
many  ways.  For  example: 

•  product  cost  is  directly  impacted  by  the  cost  of  production 
(the  process  cost) 

•  customer  response  is  directly  impacted  by  the  cycle  time  of 
associated  processes 

•  product  function  is  directly  impacted  by  the  quality  of  the 
manufacturing  process,  as  well  as  the  original  design  process 

This  realization  has  been  a  driving  force  of  the  reengineering 
paradigm.  As  businesses  roll  up  their  sleeves  to  become  more  cost 
effective,  the  first  areas  receive  attention  are  the  primary,  business 
value  stream  processes.  In  his  book  entitled  "Business  Process 
Improvement" ,  H.J.  Harrington  states: 
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In  many  companies,  management  can  make  more 

........  ..  ■■.....  ■  ■■: : 

profits  by  cutting  poor-quality  cost  in  half  than  by 
doubling  sales.  This  can  be  accomplished  without 
hiring  one  person,  building  one  new  building,  or 
finding  one  new  customer. 

The  majority  of  this  chapter,  including  the  following  section,  is 
dedicated  to  improving  process  value. 

4.4,3.  Non- Value  Added  Activities 

Value  added  activities  represent  steps  within  process  execution  that 
are  required  to  convert  process  inputs  into  process  outputs. 
Activities  which  exist  due  to  the  physical  implementation  but 
generally  do  not  improve  the  overall  quality  of  the  process  or 
product,  are  considered  non-value  added  activities.  The  following 
paragraphs  provide  an  overview  of  common  types  of  non-value 
added  activities. 

As  activities  are  evaluated  for  each  process,  the  results  of  the 
evaluation  should  be  documented  within  the  Process  Management 
Notebook  (PMN).  Notes  may  include  identification  of  the  activity, 
the  type  of  activity  (i.e.  manual,  automated),  and  the  value 
classification  (i.e.  the  reason  for  adding  or  not  adding  value  as 
described  in  the  following  subsections).  Recording  evaluation 
results  will  save  time  and  effort  during  design  activities  as  well  as 
eliminate  the  need  to  recreate  the  wheel  or  re-analyze  activities  at  a 
later  date. 

4.4.3.I.  Translator  Activity 

As  workflow  takes  place  within  a  process,  information  is 
constantly  reformatted  or  reorganized  for  use  by  subsequent 
processing  activities.  In  some  cases,  the  new  format  is  required  (by 
law  and/or  regulation)  and  therefore  activities  will  not  be  subject  to 
removal.  In  many  cases,  such  a  translation  activity  provides  no 
value  to  the  process  and  should  be  considered  for  removal. 

Translators  are  most  common  in  the  data  processing  world. 
Information  from  one  database  is  sorted,  reformatted,  and 


Record  Activity 
Evaluation  Results 
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converted  for  integration  into  another  database  to  support  later 
processing  activities.  While  identification  of  such  a  process  is  often 
easy,  the  solution  may  involve  database  redesign  or  integration  of 
disparate  systems.  Figure  4.4-2  illustrates  an  example  of  a  mailing 
list  database  maintained  in  one  format,  which  must  be  translated 
prior  to  use  by  the  automated  mailing  system  for  production  of 
labels.  The  activity  initiated  by  the  word  "Reformat"  represents  a 
non-value  added  activity. 


Figure  4.4-2.  Translator  Activity  Example 

Note  that  most  translators  operate  in  batch  mode.  Batch  processing 
typically  refers  to  processing  of  an  entire  data  set  on  a  predefined 
schedule.  As  a  result,  the  ability  to  perform  subsequent  activities  is 
delayed  until  the  batch  activity  is  executed,  even  though  the 
information  was  available  for  further  processing  at  an  earlier  time. 
Removing  batch  processing  activities  provides  an  immediate 
reduction  in  process  cycle  time. 

4.4.3.2.  Transporter  Activity 

During  process  workflow,  products  and  information  move  from 
station  to  station  throughout  the  business  enterprise.  In  many  cases, 
a  great  deal  of  time  and  effort  is  consumed  in  transporting  the 
products  to  the  next  destination.  Transportation  of  data  or  materials 
may  be  necessary  due  to  the  physical  separation  between  activities, 
but  also  may  be  an  avenue  for  major  redesign  of  a  business 
process.  If  the  cost  or  time  of  transport  is  high,  consider  the 
possibility  of  moving  activities  closer  together  or  combining 
activities. 

With  improved  communication  technology,  there  are  numerous 
possibilities  for  improving  the  movement  of  information  from 
station  to  station.  While  such  technology  solutions  do  not  remove 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


CHAPTER  4.  INNOVATION  &  REDESIGN 


Page  103 


the  transporter  activity,  the  time  and  dollars  associated  with 
moving  the  information  can  be  significantly  reduced. 

4.4.3.3.  Control  Activity  (Approvals  &  Inspections) 

Controls  are  a  primary  contributor  to  high  cycle  times  for 
processes.  Approvals  and  inspections  are  the  most  common  forms 
of  controls  placed  on  workflow.  Most  leading  analysts  recommend 
designing  in,  not  inspecting  in  quality.  The  authors  do  not 
recommend  the  wholesale  removal  of  controls,  but  do  recommend 
the  wholesale  investigation  of  controls.  Consider  whether  controls 
exist  due  to: 

•  corporate  policies  or  rigorous  regulations  which  can  not  be 
changed 

•  detection  of  problems  which  have  occurred  in  the  past 
resulting  from  poor  process  design  or  the  inadequate  nature 
of  process  execution 

•  administrative  reviews  used  to  keep  management  informed 

The  type  of  control  will  determine  the  need  for  further 
investigation  or  removal. 

4.4.3.4.  Redundant  Activity 

Redundancy  is  a  valuable  design  consideration  for  highly  critical 
systems.  Such  designs  would  place  several  activities  in  parallel  in 
order  to  ensure  continuation  of  system  operation  during  failure  of 
the  duplicate  activity.  Redundant  activities  take  many  forms  within 
a  business  enterprise  and  only  a  few  are  designed  in  to  protect 
critical  system  paths.  Most  redundant  activities  involve  the 
"rekeying"  of  information  into  a  separate  system  or  the  physical 
storage  of  information  at  several  locations  within  the  enterprise. 
Redundant  activities  are  a  major  source  of  process  waste,  as  a 
result  of: 

•  time  lost  due  to  re-entry  of  information 

•  resources  lost  due  to  additional  storage/maintenance  of 
information 
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•  data  error  increases  (less  data  integrity)  due  to  the  lack  of 
single  entry  point  with  validation 

The  search  for  redundant  activities  should  start  with  common 
sources  including  homegrown  database  systems,  applications 
which  interface  to  automated  legacy  systems,  and  manual  tasks 
from  different  organizational  units. 

4.4.3.5.  A  Chain  of  Waste 

In  many  cases,  non-value  added  activities  are  chained  together. 
Figure  4.4-3  illustrates  the  translation  of  information  into  a  new 
format  (approval  form),  the  transportation  of  information  from  a 
district  office  to  headquarters,  approval  by  management,  and  the 
subsequent  retransmittal  back  to  a  district  office. 


Figure  4.4-3.  Chain  of  Non-Value  Added  Activities 


Elimination  of  the  requirement  for  approval  of  a  price  quote  at 
headquarters  would  speed  the  delivery  price  quote  to  customers. 
Solutions  to  such  a  problem  may  include: 

•  training  of  district  staff  to  avoid  common  mistakes  audited 
by  management 

•  setting  of  thresholds  for  approval  of  smaller,  less  critical 
price  quotes 

Both  the  cycle  time  and  the  quality  of  the  price  quote  must  be 
considered  prior  to  making  design  decisions. 

4.4.3.6.  Essential  Order  &  Parallel  Processing 

Any  thorough  evaluation  of  a  process  must  examine  the  inherent 
order  of  process  activities.  Such  an  examination  considers  whether 
activities  occur  in  a  sequence  due  to  the  current  design,  or  whether 
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the  sequence  of  activities  is  essential  (meaning  that  activities  must 
be  in  the  order  presented  to  accurately  construct  process  outputs). 
Typically,  analysts  will  find  that  there  is  more  than  one  option  for 
activity  organization  to  create  process  outputs. 

Parallel  Processing  A  separate,  but  similar  issue  is  that  of  parallel  processing.  As  used 

in  this  discussion  relating  to  a  business  process,  parallel  processing 
refers  to  the  simultaneous  execution  of  process  activities  within  a 
process. 

Reorganization  of  processing  activities  can  lead  to  a  significant 
reduction  in  process  cycle  time.  Figure  4.4-4  illustrates  a  one-third 
cycle  time  reduction  associated  with  the  reorganization  of  activities 
for  a  sample  process  by  performing  two  activity  sets  in  parallel. 


Figure  4.4-4.  Reducing  Cycle  Time  using  Parallel  Processing 


4.4.3.7.  Activity  Inefficiency 

In  some  cases,  the  purpose  of  the  activity  is  value  adding,  yet  the 
existing  activity  design  itself  is  inefficient.  Such  inefficiencies  are 
often  found  as  a  result  of  performing  benchmarking  to  determine 
both  the  state-of-the-art  and  the  state-of-practice  relating  to  the 
designated  activity.  While  inefficient  activities  may  eventually  add 
value,  the  nature  of  the  existing  design  may  prohibit  adding  value 
in  the  most  productive  manner.  Further  decomposition  of  an 
inefficient  activity  may  be  necessary  to  identify  root  causes. 
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Inefficient  activities  increase  cycle  time  and  may  contribute  to 
product  defects. 

4.4.4.  Activity  based  Costing 

In  the  world  of  business,  cost  is  a  driving  factor.  In  the  world  of 
reengineering  business,  finding,  and  then  driving  out  non-value 
added  costs  is  a  major  objective. 

In  the  early  1980s,  Activity  Based  Costing  (ABC)  emerged  in  the 
private  sector  as  a  means  of  better  understanding  the  costs 
associated  with  manufacturing  processes  and  products.  ABC  has 
evolved  over  the  years  into  a  mature  approach  to  process  analysis. 
ABC  is  based  on  the  fact  that  delivery  of  products  and  services  to 
customers  drives  the  execution  of  business  activities  which 
consume  resources  (each  with  a  cost). 

ABC  is  a  two  step  process  consisting  of: 

•  activity  costing 

•  product  and  service  costing 

The  following  subsections  provide  a  brief  overview  of  each. 


4.4.4. 1.  Activity  Costing 

The  basic  premise  of  activity  costing  is  the  assignment  of  resource 
costs  to  the  activities  in  which  they  are  consumed.  Costs  are 
assigned  to  activities  via  resource  drivers,  which  are  a  means  of 
measuring  consumption  by  a  particular  processing  activity. 
Common  resource  drivers  include  some  decomposition  of  labor 
(hours)  or  materials. 

Process  activities  are  further  classified  as  part  of  ABC  into: 

•  primary  activities  -  activities  directly  supporting  delivery  of 
product  or  service 

•  secondary  activities  -  activities  supporting  primary  activities, 
but  not  directly  impacting  delivery  of  products  and  services 

•  sustaining  activities  -  activities  which  are  difficult  to 
associate  with  any  single  product  or  service 
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Primary  activities  will  often  be  assigned  costs  associated  with 
secondary  activities  in  order  to  establish  the  complete  cost  impact 
(direct  and  indirect)  of  an  activity.  The  ABC  activity  classifications 
are  similar  to  the  process  classifications  made  within  Section  3.1. 
Either  activities  are  part  of  the  process  value  stream  or  they  are 
considered  as  ancillary,  and  provide  only  indirect  support  to  the 
process. 

4.4.4.2.  Product  and  Service  Costing 

Once  appropriate  activity  costs  are  identified,  the  costs  are  further 
assigned  to  associated  products  and  services.  Activities  are 
assigned  to  products  and  services  using  activity  drivers,  which 
measure  the  demand  of  an  activity  from  the  associated  product  or 
service.  Figure  4.4-5  illustrates  the  hierarchy  of  cost  assignment 
within  the  ABC  approach.  Resources  drivers  (such  as  labor  and 
materials)  are  used  to  assign  a  single  resource  to  one  or  more 
activities.  Likewise,  activity  drivers  (such  as  the  quantity  of 
products  a  given  activity  must  generate)  are  assigned  to  the  product 
creating  the  demand. 


Figure  4.4-5.  ABC  Cost  Assignment  Hierarchy 


4.4.4.3.  ABC  Application  to  BPR 

ABC  represents  an  approach  applicable  to  reengineering  efforts. 
Inputs  from  ABC  may  be  used  to  support  cost  impact  and/or 
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economic  analysis  of  proposed  options,  as  well  as  provide  insight 
into  costs  associated  with  existing  designs.  Dynamic  modeling 
tools  (identified  in  Section  4.3)  provide  a  means  of  simulating  such 
costs  of  operation  over  time  to  further  illustrate  potential  strengths 
and  weaknesses  of  both  existing  and  proposed  design  process 
designs. 


4.4.5.  BENCHMARKING 

As  part  of  process  evaluation,  a  review  of  similar  practices  related 
to  the  business  process  being  analyzed,  both  within  and  outside  the 
industry,  is  often  conducted.  Methods  of  internal  and  external 
process  review  have  developed  into  a  formal  discipline  which 
started  at  Xerox  back  in  the  early  1980s.  Xerox  and  other  industry 
leaders  realized  that  developing  a  frame  of  reference  regarding 
how  other  industries  conduct  their  business  can  help  to  produce  a 
solution  that  is  better  fit  for  the  competitive  marketplace.  This  form 
of  comparative  analysis,  which  strives  to  identify  products  and 
processes  considered  as  "best  practice",  is  often  referred  to  as 
benchmarking.  Benchmarking  is  defined  by  Robert  Camp,  in  his 
book  "Benchmarking" ,  as: 

....  the  search  for  those  best  practices  that  will  lead  to 
the  superior  performance  of  a  company ...  and  [which] 
allows  a  manager  to  compare  his  or  her  function's 
performance  to  the  performance  of  the  same  function 
in  other  companies . 


4.4.5. 1.  Benchmarking  Categories 

Benchmarking  can  be  used  to  establish  a  variety  of  comparisons 
depending  on  the  needs  and  resources  available  to  a  business. 
James  Harrington,  in  his  book  "Business  Process  Improvement" , 
further  decomposed  benchmarking  into  four  distinct  categories  of 
comparisons,  including: 

•  Internal  -  Comparisons  to  internal  organizations  or  internal 
processes  that  are  similar  in  nature  and  used  throughout  the 
business  enterprise. 
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•  Competitive  -  Comparisons  to  competitors  in  the  market 
place.  Includes  a  review  of  how  competing  enterprise 
processes  are  designed. 

•  World-Class  -  Comparisons  to  organizations  world-wide. 

Not  limited  to  those  in  direct  competition,  or  those  in  the 
same  market  place.  This  comparison  looks  at  processes  with 
similar  goals  in  world-class  companies. 

•  Activity  Based  -  Comparisons  to  specific  processing 
activities  as  part  of  a  further  decomposition  of  a  business 
process. 

The  use  of  benchmarking  during  the  development  or  evaluation  of 
an  activity  model  can  broaden  the  design  basis  of  the  reengineering 
effort  and  steer  the  reengineering  team  towards  breakthrough 
thinking. 

4.4.5.2.  Benchmarking  Steps 

Figure  4.4-6  and  the  following  paragraphs  describe  the  basic  steps 
in  the  development  of  a  benchmarking  study,  as  outlined  by 
Spendolini  in  his  book  "The  Benchmarking  Book" . 


Figure  4.4-6.  Five  Stage  Benchmarking  Process 
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1.  Determine  What  to  Benchmark  -  Initial  efforts  should  be 
focused  on  identifying  the  customers  and  their  associated 
requirements  for  further  study.  Once  identified,  specific 
benchmarking  subjects  may  be  defined  and  the  resources 
(e.g.,  people,  time,  dollars)  necessary  for  benchmarking 
studies  can  be  better  estimated.  Since  earlier  chapters  of 
this  document  have  directed  attention  toward 
customer/process  definition,  this  benchmarking  task  should 
take  less  effort  to  complete. 

2.  Form  a  Benchmarking  Team  -  Larger  organizations  will 
need  a  team  to  complete  the  diverse  tasks  necessary  for 
successful  benchmarking. 

3.  Identify  Benchmarking  Partners  -  Timely  and  accurate 
sources  of  information  for  comparison  are  critical  to  the 
benchmarking  process.  During  this  step,  information 
sources  such  as  consultants,  trade  literature,  industry 
reports,  and  databases  may  be  helpful.  Team  members 
should  seek  ways  to  identify  best  practices  for 
organizations  with  similar  process  requirements. 

4.  Collect  &  Analyze  Benchmarking  Information  - 
Benchmarking  data  are  collected  from  key  sources 
identified  in  Step  3.  This  information  is  reviewed  and 
analyzed  to  determine  process  characteristics  common  to 
best  practice  organizations.  Resulting  data  are  used  to 
establish  action  plans. 

5.  Take  Action  -  Actions  from  benchmarking  may  range  from 
the  need  to  perform  further  investigations  to  identification 
of  potential  new  designs  for  review. 

Benchmarking  should  be  viewed  as  cyclic  in  nature.  A  circular 
benchmarking  approach  promotes  continuous  comparisons  to  best 
practice  organizations. 
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4.4.S.3.  Utilizing  Benchmarking  Results 

Benchmarks  may  also  be  shown  in  a  graphical  form  as  illustrated 
in  Figure  4.4-7.  The  spokes  represent  different  processes  of  interest 
and  the  circle  represents  the  best  quality  found  anywhere.  The 
polygon  inside  the  circle  intersects  each  spoke  at  a  point 
representing  the  benchmarking  company's  level  of  achievement 
relative  to  "world  class"  performance. 


Figure  4.4-7.  Process  Benchmark  Graphic 

If,  for  example,  its  products  were  half  as  reliable  as  the  best  similar 
products,  measured  by  the  mean-time-between-failure,  the  polygon 
would  intersect  the  reliability  spoke  half  way  from  the  hub  to  the 
circle.  Assuming  that  an  appropriate  figure  of  merit  is  used,  such  a 
graphic  gives  a  quick  picture  of  the  company's  position  relative  to  a 
given  process  goal. 
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4.4.6.  Case  Study  Example 


Case  Study  J§ 


The  following  paragraphs  provide  a  brief  overview  of  the  existing 
"as-is"  processing  activities  targeted  for  reengineering  by  CSK, 
along  with  a  summary  of  process  evaluation  results  completed  by 
CSK. 


4.4.6.I.  Existing  "As-Is"  Process  Design 


The  existing  CSK  process  design  was  fragmented  and  not 
organized  to  support  smooth  process  workflow.  Separate  work 
areas  existed  to  support  process  activities,  as  illustrated  in  Figure 
4.4-8. 


Note:  P&ID  =  Piping  and  Instrumentation  Diagram 


P&ID:  Initial  P&ID  information  is  extracted  from  proposal  efforts  and  used  to  generate  an  electronic  P&ID  Diagram 
with  key  unit  design  components  manually  collected  by  engineering  for  a  parts  listing  and  manually  sized  and  placed 
into  2-D  physical  design  drawings.  Non-key  components  were  made  available  to  purchasing  in  paper  form  and 
reformatted  for  order. 

Instrumentation:  Engineering  staff  utilize  P&ID  diagrams  to  carefully  establish  a  list  of  major  instrumentation  and 
manually  enter  them  into  a  spreadsheet.  Spreadsheets  are  then  passed  to  subsequent  design  and  purchasing  staff. 

Sizing:  Engineering  staff  manually  develop  design  calculations  on  paper  for  key  equipments  and  pass  results  to 
subsequent  design  and  purchasing  staff  for  further  processing. 

2-D  Physical  Design:  Designers  lay  out  the  design  of  the  physical  skids  using  2-D  drawing  tools  and  hardcopy  P&ID 
diagrams.  2-D  diagrams  and  resulting  components  are  passed  to  purchasing  staff  for  further  processing. 

Electrical  Design:  Engineering  staff  utilize  P&ID  diagrams  to  manually  enter  a  list  of  major  motors  on  a  spreadsheet 
and  work  with  the  designer  to  produce  non-intelligent  one-line  and  PLC  logic  diagrams.  A  manual  list  of  PLC 
components  is  produced  from  the  diagram  and  passed  to  purchasing. 

Purchasing:  Purchasing  receives  either  spreadsheet  printouts  or  handwritten  lists  of  parts  for  further  order  processing. 


Figure  4.4-8.  CSK  Example  :"As-Is"  Process  Design 
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4.4.6.2.  Process  Evaluation 

Reengineering  team  members  reviewed  the  existing  "as-is"  process 
design  and  identified  a  series  of  design  deficiencies.  Figure  4.4-9 
lists  the  primary  design  deficiencies  noted  by  CSK  and  identifies 
the  representative  value  category  impacted  (as  described  in  Section 
4.4). 


Reported  Process  Deficiencies 

Process  Value 
Categories 

j  No  Common  Data  Repository:  -  CSK  noted  that  information  was 
managed  separately,  redundantly,  and  inefficiently  in  each  activity 
work  area. 

Transporter,  Redundancy 

j  Lack  of  Real-World  (3-D)  Design  Support:  CSK  noted  that 
\\jrl  designers  were  able  to  think,  but  not  complete  work  in  a  3-D 

environment.  The  customized  nature  of  CSK  designs  requires  that 
equipment  be  custom  fit,  per  customer  requirements,  into  a  three 
dimensional  area. 

Process  Inefficiency 

j  Poor  Data  Handoff  -  Sharing:  CSK  noted  that  data  and  supporting 

1 J documents  produced  in  one  work  area  were  manually  transported  for 
use  in  the  next,  often  requiring  further  translation  into  new  formats. 

Transporter,  Translator, 
Redundancy 

j  Activity  Inefficiencies:  CSK  noted  that  fundamental  activities  such  as 

1  sizing  and  electrical  design  were  not  supported  by  intelligent  tools 
identified  as  a  result  of  simple  market  bechmarking. 

Process  Inefficiency 

j  Poor  Design  Documentation  Control:  CSK  noted  that  documentation 
within  the  enterprise  was  managed  and  controlled  almost  exclusively  in 
a  manual  manner.  While  some  of  the  controls  were  required,  common 
order  of  precedence  policies  were  not  in  place  to  improve  design 
workflow. 

Transporter,  Control, 
Translator,  Essential  Order. 
Redundancy 

Figure  4.4-9.  CSK  Example:  Process  Evaluation 
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4.5.  process  Redesign  ("To-Be”) 

The  time  has  come  to  redesign.  The  word  redesign  may  have 
different  meanings  to  different  people.  To  some,  redesign  conjures 
up  images  of  an  architect  redrawing  blueprints  after  the  initial 
designs  were  rejected.  To  others,  redesign  reflects  a  more  cultural 
and  environmental  change. 

Readers  should  remember  that  redesign  is  meant  to  work  hand-in- 
hand  with  process  evaluation  as  shown  in  Figure  4.5-1  and 
discussed  in  previous  sections.  Redesign  without  re-evaluation 
could  represent  a  significant  risk  to  a  business  enterprise. 


Figure  4.5-1.  Design  -  Evaluation  Iteration 

This  section  addresses  process  redesign  from  both  a  technical  and 
social  point  of  view  with  an  eye  on  adding  value  to  the  process  as  a 
whole. 

4.5.1.  TECHNICAL  REDESIGN 

The  technical  design  of  a  business  process  results  in  the  optimum 
organization  of  physical  parts  in  order  to  create  a  new  process  with 
maximum  efficiency  and  product  quality.  Common  process 
measurements  of  a  technical  design  include  process  cycle  time  and 
defect  rates.  This  section  addresses  key  aspects  of  technical 
redesign,  including: 

•  maintaining  a  workflow  emphasis  on  the  business  process, 
starting  with  the  ideal  process  design 
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•  integrating  constraints  to  design  which  limit  process  design 
freedom 

•  examining  data  integration  to  support  process  workflow 

•  identifying  where  enabling  technology  can  be  used  to 
immediately  impact  process  workflow  solutions 

•  investigating  standardization  of  common  processes 
throughout  the  business  enterprise  as  a  means  of  improving 
workflow  productivity 

•  considering  off-the-shelf  solutions  as  mechanisms  to  quickly 
transform  the  process 

•  utilizing  prototypes,  where  possible,  to  review  design 
solutions  prior  to  full-scale  development  and  deployment 

•  eliminate  pockets  of  excellence  where  possible  with  a 
process 

•  creating  a  new  process  model  for  evaluation 

4.5.1. 1.  Workflow  Emphasis 

The  definition  of  a  business  process  (Chapter  3)  encompasses  the 
transformation  of  business  inputs  into  business  outputs.  The 
collection  of  activities  performed  within  a  process  to  complete  this 
transformation  embody  the  workflow  concept.  Workflow  consists 
of  a  compound  of  two  distinct  words  and  associated  definitions: 

work  =  effort  to  overcome  obstacles  and  achieve  an  objective 
or  result 

flow  =  to  proceed  smoothly  and  readily 

Start  With  Ideal  Process  The  ideal  process  design  established  as  part  of  creating  a  process 

Design  vision  represents  the  required  workflow,  the  set  of  activities  which 

must  exist  to  complete  the  desired  process.  Therefore,  the  ideal 
process  design  represents  the  foundation  for  creating  the  new 
process  design,  or  "to-be"  process  model.  Note  that  the  ideal 
process  design  may  have  little  or  no  process  architecture  layers, 
since  the  integration  of  constraints  and  technology  have  not  yet 
occurred. 
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Technical  Design  Results  The  new  process  design  must  provide  visibility  into  the  process 

workflow,  as  well  as  the  process  architecture  (anatomy).  Such  a 
design  should  illustrate  how  work  (completed  by  value  adding 
activities)  transforms  inputs  into  outputs  within  the  various  levels 
of  process  architecture.  The  following  diagram  provides  a 
workflow  view  of  a  business  process. 


4.5.L2.  Constraints  to  Design 

Most  (if  not  all)  business  executives  are  unwilling  to  sign  a  blank 
check  for  process  redesign.  The  constraints  placed  on  process 
redesign  can  take  many  forms  and  often  limit  the  freedom  to 
design  innovative  process  solutions.  The  most  common  design 
constraints  are  those  relating  to  time,  money,  and  existing  systems. 
Other  constraints  may  include: 

•  development  resource  limitations  (time,  money,  people,  etc.) 

•  applicable  regulations  and  standards 

•  rigid  external  interfaces 

•  size  or  space  limitations 

•  staff  capabilities  and  experience 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


CHAPTER  4.  INNOVATION  &  REDESIGN 


Page  117 


Integrate  Constraints 
into  New  Process  Model 


•  parallel  efforts 

•  possible  schedule  conflicts 

•  technologies  acceptable  to  management 

•  political  ramifications 

As  many  constraints  as  possible,  both  expressed  and  implied,  need 
to  be  identified  and  challenged.  Availability  of  a  comprehensive 
assessment  of  constraints  at  this  stage  helps  designers  to 
understand  limitations  and  minimize  time  wasted  on  untenable 
solutions. 


Questions  which  may  help  the  designer  to  focus  on  constraints  may 
include: 


Is  there  a  known  budget  to  support  the  process 


redesign l 


. . . s-:a«BSp:*aS“8 

* 


If  we  recommend  new  technology,  will  there  be 
to  purchase  it? 

Are  any  existing  systems  Or  activities  sacred  or  can  we 
target  the  entire  process? 

Are  there  corporate  standards  which  should  be 
considered  as  a  model  for  new  process  design? 


Once  constraints  have  been  clearly  identified,  the  impact  of 
constraints  can  be  integrated  into  the  "to-be” process  model.  At  this 
point,  the  new  process  model  exists  as  a  compound  of  the  ideal 
process  design  (vision  features)  and  the  embedded  design 
constraints. 

Since  the  ideal  process  model  typically  has  no  architecture  layers, 
the  result  of  integrating  constraints  will  often  be  the  first  overlay  of 
process  architecture  layers  on  to  the  "to-be"  process  model.  If  an 
existing  software  system  for  producing  quotes  was  just  purchased 
and  will  be  used  "as-is",  then  the  new  process  model  should  be 
updated  to  show  interfaces  (manual,  automated,  and  data)  to  the 
existing  quoting  system.  The  new  process  model,,  including 
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Record  Constraints 


Constraints  are  Not 
Forever 


overlaid  constraints,  now  becomes  the  baseline  for  further  process 
design  discussions. 

It  is  not  enough  to  quickly  integrate  constraints  into  the  new 
process  model  and  then  forget  why  they  exist  or  where  they  apply. 
Without  documenting  (in  a  reusable  form)  the  constraints 
identified,  designers  will  waste  valuable  time  rethinking  previous 
process  decisions  without  understanding  that  such  a  discussion  is 
likely  of  no  value.  Those  organizations  using  automated  process 
modeling  tools  may  choose  to  embed  documentation  of  constraints 
directly  into  process  models.  Regardless  of  the  documentation 
approach,  constraints  should  be  incorporated  into  the  Process 
Management  Notebook. 

Each  time  that  a  process  is  revisited  to  review  potential  redesign 
alternatives,  the  same  level  of  questioning  must  be  re-applied. 
Often  the  discussion  can  be  limited  to  " Are  the  previous  process 
constraints  still  valid?"  and  "Are  there  any  new  constraints  that 
should  be  considered?". 


4.5.I.3.  Data  Integration 


The  majority  of  business  process  workflow  centers  around  the 
interfaces  between  people  and  data.  Without  adequate  technologies 
to  support  integration  of  disparate  systems,  existing  processes  were 
constructed  as  islands  resulting  in  mass  data  redundancies,  large 
volumes  of  hard  copy  documents,  data  inconsistencies,  and  wasted 
effort  in  data  manipulation.  The  advent  of  personal  computers, 
along  with  easy-to-use  desktop  database  tools,  caused  many 
employees  to  build  local  databases  to  capture  critical  information, 
decreasing  the  likelihood  of  an  integrated  data  solution. 

The  sections  which  follow  discuss  how  advances  in  Information 
Technology  (IT)  have  enabled  the  integration  of  databases.  The 
most  important  fact  to  consider  is  that  business  enterprise 
managers  now,  more  than  ever,  have  realized  the  importance 
(value)  of  data  as  the  foundation  to  business  process  innovation 
and  redesign.  It  should  also  be  noted  that  the  topics  presented  may 
be  generalized  to  address  integration,  without  the  emphasis  on  IT. 
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Data  Forms  the  Basis  of 
Business  Process 
Knowledge 


Data  Organization  & 
Access 


Data  Anatomy 


As  a  result  integration  efforts,  the  term  Data  Repository  has  risen 
to  the  forefront.  Data  repository  refers  to  an  organized  collection  of 
business  enterprise  data  managed  in  a  manner  promoting 
standardized  data  definitions  (element  names,  definitions)  as  well 
as  centralized  access  and  maintenance  (non-redundant,  where 
possible).  As  a  result  of  the  data  repository  concept,  many 
organizations  choose  to  study  data  integration  as  a  means  of  better 
understanding  process  workflow. 


\ 

V 
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Workflow  -  People 

IV 

k 

Automation  -  Applications 

Data  -  Repository 

Foundation 

/ 


Figure  4.5-3.  Data  as  Value  Added  Foundation 


The  value  of  data  must  never  be  underestimated.  Proper  use  of  data 
can  provide  a  perspective  of  the  past,  the  status  of  the  present,  and 
insight  into  the  future. 

The  value  of  data  to  an  organization  is  completely  dependent  on 
data  organization  and  access.  Data  has  limited  value  when 
unaccessable  to  those  needing  the  information.  In  addition,  easy 
access  to  unorganized  information  results  in  data  of  little  value. 

Much  in  the  way  that  business  and  process  anatomy  have  been 
discussed,  understanding  data  anatomy  is  also  a  necessity.  A  high- 
level  view  of  data  organizational  concepts  results  in  a  discussion  of 
Entities,  Instances,  and  Attributes. 

•  Entities  -  A  logical  grouping  of  data  relating  to  a  common 
object.  The  term  entity  is  most  closely  related  to  the  term  file 
or  table  in  the  database  world.  For  example,  a  customer 
would  be  considered  an  entity. 

•  Instances  -  A  set  of  data  relating  to  a  particular  entity.  The 
term  instance  is  most  closely  related  to  the  term  record  in 
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the  database  world.  There  may  be  many  customer  instances 
for  a  single  entity. 

•  Attributes  -  The  individual  pieces  of  data  elements 
describing  the  entity  on  this  specific  instance.  The  term 
attribute  is  most  closely  related  to  the  term  field  or  column 
in  the  database  world.  There  would  typically  be  many 
attributes  (fields)  describing  a  particular  customer. 

Figure  4.5-4  illustrates  the  relationship  between  the  elements 
contributing  to  data  organization. 

Entity 


Instances 


Figure  4.5-4.  Data  Organization 

Data  Relationships  jn  most  organizations,  many  entities  exist.  The  relationship 

between  entities  is  often  illustrated  graphically  via  data  models,  the 
most  common  being  an  Entity  Relationship  Diagram  (ERD).  While 
there  are  many  formalisms  used  for  graphical  presentation  of 
ERDs,  the  goal  of  each  is  to  clearly  show  the  connections  between 
entities  including  how  entities  are  related,  dependencies  between 
entities,  and  data  attributes  which  are  commonly  used  to  link 
entities.  Figure  4.5-5  illustrates  the  relationships  between  the 
customer,  order,  and  product  entities  for  a  given  organization.  This 
simplified  illustration  shows  that  more  than  one  order  may  exist 
for  a  single  customer  and  that  more  than  one  product  may  be 
associated  to  a  single  order.  Additional  characteristics  can  be 
added  to  such  a  diagram  to  indicate  more  detailed  relationships. 
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Coupling  and  Cohesion 


Figure  4.5-5.  Example  Entity  Relation  Diagram  (ERD) 


The  use  of  data  models  can  be  critical  in  identifying  the  degree  of 
coupling  between  portions  of  a  business.  Even  within  a  single 
business  process,  islands  of  data  may  surface  which  allow 
designers  to  further  decompose  process  solutions  into  digestible 
modules. 


Highly  Cohesive 


Figure  4.5-6.  Data  Islands 
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Ideal  Data  Model 


Data  Model,  Data 
Collection 


While  many  automated  business  enterprise  modeling  tools  are  still 
in  their  infancy,  automated  data  modeling  tools  are  relatively 
mature.  Such  tools  provide  for  quick  collection,  definition,  and 
organization  of  business  data. 

Much  as  an  ideal  process  model  may  be  created  as  a  guide  for 
process  improvements,  an  ideal  data  model  can  be  used  to  guide 
information  innovations.  As  with  the  process  model,  the  ideal  data 
model  is  only  concerned  with  the  logical  organization  and 
relationships  between  data,  not  the  physical.  For  example,  existing 
customer  information  may  currently  be  stored  in  a  variety  of  places 
including  the  computer,  filing  cabinets,  and  in  staff  rolodexes.  The 
logical  data  model  would  extract  and  combine  attributes  from  these 
sources  into  a  single  entity  without  regard  to  the  existing  storage 
medium. 

Collecting  information  to  properly  construct  a  data  model  can  be 
similar  to  looking  for  a  contact  lens,  you  know  that  it's  there,  but 
you  may  step  on  it  before  you  find  it. 

While  existing  automated  systems  will  provide  quick  reference  to 
attributes,  the  organization  of  existing  system  data  must  be 
thoroughly  examined  prior  to  use.  Many  fields  in  existing  system 
databases  exist  only  to  supplement  the  deficiencies  of  a  past 
technology  solution.  To  collect  the  most  comprehensive  set  of  data 
attributes  often  requires  asking  staff  targeted  questions  such  as: 

What  information  do  you  need  to  make  the  most 

effective  decision  or  to  complete  a  desired  activity? 

Notice  that  the  question  did  not  ask  for  the  data  currently  used  or 
the  data  currently  available  since  such  questions  would  restrict  the 
potential  answer.  The  idea  is  to  capture  all  of  the  business  process 
activity  knowledge  as  part  of  performing  the  activity. 

Once  an  ideal  data  model  is  constructed  (or  at  least  80%  of  the 
model),  then  work  may  begin  to  determine  what  enabling 
technologies  may  be  used  to  organize,  store,  manipulate,  and 
deliver  the  required  data  to  workflow  activities. 
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The  use  of  the  80-20  principle  to  speed  reengineering  activities  is 
discussed  in  Section  4.1.1. 


4.5.I.4.  Enabling  Technology,  Creating  a  Foundation 

A  historical  review  of  enabling  technology  impacts  on  business 
points  back  to  the  studies  conducted  by  Joanne  Yates  from  1850  to 
1920.  While  primitive  in  nature,  these  studies  led  to  the  integration 
of  innovative  new  approaches  to  communications  and  information 
storage  such  as  telegraphs,  telephones,  and  vertical  filing  cabinets. 
Over  time,  such  advances  have  become  outdated  or  commonplace 
to  business,  much  as  today's  technology  will  someday  be  antique. 

Information  Technology  During  the  last  decade,  a  variety  of  technologies  has  advanced  in 

depth  and  breadth,  but  none  has  had  a  greater  impact  on  business 
process  transformation  than  Information  Technology  (IT). 
Therefore,  this  section  will  focus  on  the  use  of  IT  in  business 
process  redesign. 

No  More  Excuses  Faster  computers,  graphical  interfaces,  client/server  applications, 

and  open  database  architectures  have  given  a  complete  facelift  to 
information  management.  For  years,  information  managers  used 
excuses  blaming  computer  hosts  and  database  engines  that  could 
not  be  cost  effectively  interfaced. 

As  part  of  process  redesign,  the  question  becomes  "How  can 
Information  Technology  be  effectively  applied  to  my  specific 
business  process  needs!".  The  answer  depends  on  the  nature  of 
change  desired.  N.  Venkatraman,  in  the  book  entitled  "The 
Corporation  of  the  1990's ",  identified  five  stages  of  Information 
Technology-induced  business  changes: 

•  Localized  Exploitation  -  use  IT  to  improve  existing 
processes  (normally  within  one  business  function) 

•  Internal  Integration  -  build  an  electronic  infrastructure,  or 
platform,  for  the  organization  to  integrate  functions 

•  Business  Process  Redesign  -  fundamentally  rethink  the  most 
effective  ways  to  conduct  business 


Reliability  Analysis  Center  •  P.O.  Box  4700 «  Rome,  NY  13440-4700  •  (315)  337-0900 


Page  124 


CHAPTER  4.  INNOVATION  &  REDESIGN 


•  Business  Network  Redesign  -  use  IT  to  include  all  suppliers, 
customers,  etc.,  who  can  contribute  to  the  organization's 
effectiveness  (one-to-one  or  market  linkage) 

•  Business  Scope  Definition  -  decide  to  exploit  new 
technology  in  the  marketplace  (or  in  products);  get  into 
additional  new  businesses 


A  Word  of  Caution 


While  this  document  focuses  on  business  process  redesign, 
additional  stages  of  IT-induced  change  are  also  applicable. 


It  is  important  to  remember  that  Information  Technology  is  not  a 
business  savior,  only  a  set  of  tools  which  may  help  improve 
process  workflow.  Using  technology  without  a  business  process 
focus  often  results  in  the  same  "choke-hold"  currently  exhibited  by 
existing  legacy  systems.  Hammer  and  Champy,  in  their  book 
"Reengineering  the  Corporation" ,  caution  that: 

Information  technology  plays  a  crucial  role  in  business 
reengineering,  but  one  that  is  easily  miscast.  Modern, 

. 

state-of-the-art  information  technology  is  part  of  dhy 
reengineering  effort,  an  essential  enabler  since  it 
permits  companies  to  reengineer  business  processes. 

But  merely  throwing  computers  at  an  existing  business 

. 

problem  does  not  cause  it  to  be  reengineered.  In  fact, 
the  misuse  of  technology  can  block  reengineering 
altogether  by  reinforcing  old  ways  of  thinking  and  old 


behavior  patterns. 


as 


llililillill! 


The  Latest  Enablers  A  variety  of  new  software  tools  tighten  the  gap  between  process 

workflow,  document  management,  and  data.  These  relatively  new 
classes  of  enablers,  are  generally  categorized  into  workflow  and 
groupware  products.  Groupware  solutions  have  captured  the 
attention  of  businesses  by  integrating  data,  forms,  communication, 
and  staff  workflow  in  a  cooperative  working  environment. 

Many  of  the  workflow-based  enablers  are  built  on  the  use  of 
client/server  type  architectures. 
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Client/Server  The  tremendous  increase  in  the  use  of  personal  computers  (PCs) 

along  with  the  parallel  increase  of  PC  performance  and  tools,  has 
resulted  in  a  demand  for  desktop  manipulation  of  data. 
Client/Server  technology  utilizes  a  desktop  computer  (client)  as  a 
means  of  inquiry  to  a  more  centralized  computer  (server)  acting  as 
a  common  data  storage  facility.  The  server  computer  provides  data 
requested  back  to  the  client.  While  there  are  several  variations  to 
this  model,  the  basic  architecture  is  illustrated  in  Figure  4.5-7. 


Figure  4.5-7.  Client/Server  Architecture  Overview 


Document  Management 
and  Imaging 


Consider  Acquisition, 
Development  & 
Maintenance  Cost 


Among  the  major  technology  advancements  is  that  of  document 
management  and  document  imaging.  Mass  storage  devices, 
combined  with  high-resolution  scanners  and  graphical  interfaces, 
have  provided  a  means  of  eliminating  the  mountains  of  paperwork. 
Organizations  littered  with  high-volumes  of  physical  documents 
are  strongly  considering  the  advantages  of  maintaining  on-line 
images  as  a  means  of  reducing  document  management  costs  and 
user  access  time,  thus  reducing  process  cycle  time. 

Regardless  of  the  technology  selected,  it  is  critical  to  consider 
more  than  the  aesthetics.  Many  of  the  emerging  technology 
solutions  offer  substantial  breakthroughs  in  workflow,  but  also 
may  demand  significant  resources  for  development  and 
maintenance.  State-of-the-art  technology  often  lacks  maturity,  is 
less  tested,  and  therefore  may  represent  a  significant  risk  to 
successful  implementation. 
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4.5. 1.5.  Standardization 


The  larger  the  business  enterprise,  the  greater  the  value  of  common 
tools,  procedures,  and  systems.  Standardization  decisions  are 
difficult,  since  there  is  rarely  a  solution  that  meets  all  of  the  needs 
of  all  those  involved.  Choosing  a  standard  typically  involves 
selecting  a  solution  which  only  provides  80%  of  the  features  that 
are  required  by  all  organizations  throughout  the  enterprise. 
Implementation  of  a  standardized  solution  must  allow  for 
customization  of  processes  (within  limits)  to  meet  local 
organization  needs. 

Advantages  of  Common  Used  properly,  standards  can  improve  operational  efficiency  by: 

Processes 

•  reducing  training  due  to  the  common  nature  of  the  business 
environment 


Structured  Processes 
Should  not  Discourage 
Creativity 


•  increasing  productivity  through  well  defined,  commonly 
used  processes 

•  reducing  purchase,  deployment,  and  maintenance  costs  due 
to  the  cost  benefits  of  economy  of  scale 

•  reducing  time  spent  in  translation  of  information  between 
functions,  areas,  or  systems  by  creating  greater  compatibility 

The  major  downside  to  standardization  is  in  the  area  of  restricted 
creativity.  An  innovative  organization  must  continually  review  and 
test  the  standard  processes  to  ensure  business  goals  are  achieved. 
The  goal  of  standardization  is  to  create  common,  well  defined 
processes  throughout  large  business  enterprises,  not  to  discourage 
creative  thinking  and  innovative  process  solutions. 


4.5.I.6.  Off-the-Shelf  Solutions 

Packaged  solutions  which  have  been  developed,  tested,  and 
implemented  to  support  similar  business  processes  may  provide  for 
immediate  process  improvement.  Such  solutions  are  available  from 
commercial  organizations  and  referred  to  as  Commercial-Off-The- 
Shelf  (COTS),  or  from  government  organizations  and  referred  to  as 
Government-Off-The-Shelf  (GOTS).  Pre-packaged  solutions,  or 
sets  of  software  and  procedures  which  are  available  for  immediate 
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4.5.I.7.  Prototypes 


Remember,  It's  a 
Prototype 


insertion  into  redesigned  processes,  may  also  be  referred  to  as 
Non-Developmental  Items  (NDIs). 

As  discussed  in  Section  4.5. 1.5  (previous  section)  relating  to 
standardization,  selecting  off-the-shelf  tools  will  often  requires 
accepting  a  solution  which  does  not  map  exactly  to  the  target 
business  process  needs,  but  may  provide  a  means  for  quickly 
achieving  process  improvements  of  degree  over  the  existing 
process  design. 


New  application  development  tools  have  increased  the  ability  of 
software  developers  to  construct  prototypes  of  proposed  software 
solutions.  Rapid  prototypes,  and  similar  concepts  such  as  Rapid 
Application  Development  (RAD),  are  used  to  construct  a  skeleton 
system  which  can  be  screened  by  users  prior  to  initiating  full-scale 
development  activities.  Prototypes  provide  insight  into  operational 
problems,  design  deficiencies,  and  potential  enhancements  which 
would  otherwise  be  unknown  prior  to  completion. 

While  software  process  prototypes  are  common,  business  process 
prototypes  are  much  less  common.  A  business  process  prototype 
would  consist  of  a  drafted  set  of  operational  procedures,  software, 
and  simulated  data  to  create  a  real-world  skeleton  of  a  business 
process.  Utilizing  business  process  prototypes  reduces  the  risk  of 
restructuring  business  functions,  people,  software,  and  data  without 
a  known  process  or  product  value. 

Too  often,  prototypes  are  so  well  liked  that  they  become  the  new 
system.  Since  the  prototype  was  not  originally  intended  to  hold-up 
under  the  stress  of  the  operational  process,  the  prototype  is  likely 
to  fail  as  a  full-scale  solution.  The  critical  point  is  to  ensure  that  all 
personnel  involved  (developers,  users/testers,  and  managers) 
understand  the  purpose  of  the  prototype  and  the  need  to  perform 
more  rigorous  design  prior  to  user  deployment. 
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4.5.I.8.  Pockets  of  Excellence 

A  pocket  of  excellence  is  a  term  coined  by  noted  author  Tom  Peters 
to  identify  an  area  or  activity  set  within  a  business  enterprise  that 
exhibits  extreme  efficiency  in  comparison  to  the  rest  of  the 
business  enterprise.  Generally,  a  pocket  of  excellence  is  considered 
a  negative  term  since  an  isolated  efficient  area  can  contribute  to 
overload  within  other  activity  sets,  and  may  therefore  have  little  or 
no  net  effect  on  overall  process  improvement. 

Designers  should  be  careful  not  to  overdesign  a  single  segment  of 
the  business  enterprise  without  considering  the  balance  needed  to 
support  smooth  workflow  throughout  each  business  process. 


4.5.I.9.  Creating  a  New  Process  Model 

As  each  of  the  aspects  discussed  are  integrated  into  the  process 
design,  a  new  process  model  emerges.  The  new  process  model 
must  then  be  evaluated  to  ensure  that  changes  have  the  desired 
impact  on  business  goals. 

Process  modeling  including  activity  modeling,  static  modeling, 
and  dynamic  modeling  are  discussed  in  section  4.3  of  this 
document. 


Record  New  Process 
Design 


Once  a  new  process  design  has  been  evaluated  and  meets  the 
desired  business  goals,  the  new  process  design/model  must  be 
incorporated  into  the  Process  Management  Notebook.  This  new 
design  represents  the  "to-be"  view  of  the  process  and  acts  as  a 
roadmap  for  process  changes.  Additional  notes  relating  to  why 
specific  design  decisions  were  made  should  also  be  recorded 
during  this  stage. 


4.5.2.  SOCIAL  DESIGN 

Process  reengineering  involves  more  than  just  process  diagrams 
and  the  insertion  of  new  technology.  People,  attitudes,  and 
environment  can  be  of  equal  importance.  Changing  people  is  more 
difficult  than  changing  computer  systems.  The  existing  business 
process  design  is  embedded  in  the  minds  of  current  process 
workers,  resulting  in  a  pride  of  ownership. 
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Large  business  processes  must  also  be  socially  designed  in  order  to 
reap  the  benefits  of  reengineering.  Many  questions  may  exist  at 
this  stage,  including: 

•  How  many  levels  of  management  hierarchy  are  really 
needed  to  successfully  execute  this  process  on  a  day-to-day 
basis? 

•  What  are  the  types  of  leaders  necessary  to  manage  the 
resulting  levels  of  the  new  business  process? 

•  How  much  change  is  being  introduced  into  the  business 
process,  and  how  will  workers  react  to  the  change? 

•  Are  there  new  roles  and  responsibilities  resulting  from  new 
process  designs? 

•  How  can  management  improve  the  commitment,  trust,  and 
sense  of  ownership  supporting  new  process  designs? 

The  answers  to  these  critical  questions  can  provide  insight  into 
characteristics  of  a  new  social  structure. 

4.5.2. 1.  Organizational  Hierarchy 

The  more  levels  of  hierarchy,  the  more  administrative  burdens  are 
placed  on  an  organization,  and  the  more  difficult  it  becomes  to 
effectively  communicate.  Both  public  and  private  business  trends 
are  toward  flattening  of  the  organizational  structure  (illustrated  in 
Figure  4.5-8),  reducing  levels  where  appropriate,  and  increasing 
communication  and  empowerment  at  the  remaining  levels. 
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Results: 

•  Flattened  Organizational  Structureless  Layers) 

•  Reduced  Gap  Between  Senior  Management  and  Process  Workers 

•  Increased  Staff  Empowerment 


Figure  4.5-8.  Organizational  Structure  Changes 

Reduction  in  organizational  levels  reduces  the  gap  between 
management  and  process  workers,  making  management  more 
aware  of  process  workflow. 

4.5.2.2.  Roles  and  Responsibilities 

As  part  of  the  new  process  design,  it  is  likely  that  people  (process 
workers)  may  be  cast  into  different  roles  and  responsibilities. 
While  the  basic  process  architecture  layers  exist,  new  designs  have 
likely  disturbed  or  shifted  the  interfaces  within  the  business 
environment  (see  Figure  4.5-9),  including  interfaces  between 
people,  computers,  and  physical  infrastructure.  Personnel  will 
sometimes  feel  violated  by  the  new  design,  since  it  may  replace 
manual  activities  with  automated  activities  or  completely  replace 
previous  job  functions. 
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Workflow  Focus 


Figure  4.5-9.  New  Process  Design  Architecture 

As  mentioned  in  Chapter  1,  managing  the  threat  of  change 
resulting  from  new  process  designs  represents  a  critical  factor  in 
the  new  process  success  or  failure.  Well  defined  roles  and 
responsibilities,  as  a  minimum,  provides  process  workers  with  the 
truth  as  opposed  to  their  existing  perceptions  of  change. 

Team  members  should  be  careful  to  remember  that  the  goal  of  the 
new  process  design  is  to  improve  the  quality  (speed,  integrity,  etc.) 
of  process  workflow. 

Staff  roles  and  responsibilities  should  be  established  which 
maximize  process  workflow  by  improving  communications, 
clearly  defining  personnel  assignments,  encouraging  creativity,  and 
to  the  extent  possible,  empowering  process  workers. 
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Responsibility  Definition 


Social  design,  including  the  staff  responsibilities  supporting  the 
new  organizational  structure  and  process  workflow,  must  be 
clearly  described  within  the  Process  Management  Notebook.  In 
addition,  changes  to  management  philosophies  (outlined  in  the 
following  paragraphs)  are  also  documented. 


4.5.2.3.  New  Management  Philosophy 


Process  reengineering  is  meaningless  if  the  resulting  process 
improvements  are  temporary.  To  ensure  that  process  improvements 
are  lasting  and  that  the  process  continues  to  evolve  towards  desired 
business  goals,  the  organization  culture  must  also  be  adapted. 
Maintaining  a  business  process  focus  requires  that  a  participative 
management  philosophy  be  employed  which  encourages  team 
thinking  and  involves  team  members  in  implementing  process 
improvements.  A  participative  management  philosophy  empowers 
employees  by  giving  them  authority  and  responsibility  for 
improving  their  work  processes.  It  should  be  noted  that  the  new 
teamwork  environment  does  not  lessen  management  commitment 
to  process  improvement.  Dr.  Frohman,  in  an  Industry  Week  article 
in  1988  entitled  "What  it  Takes  to  Make  it  Work" ,  states  that: 


Participative  Management  does  nett  eliminate  the 
manager's  rale  or  reduce  his  accmhtdhiHfyfor  results. 
ftetHer,  att&niipn  to  solfgUing 

integrating 

^i^rsefnpiuf  ahiTtnmagmg  group  processes. 


In  a  more  recent  Industry  Week  article,  Dr.  Frohman  identifies 
seven  characteristics  of  participative  managers. 

1.  They  have  a  clear  understanding  of  the  purpose  and 
direction  of  the  organization. 

2.  They  have  high-performance  expectations  of  themselves 
and  others. 

3.  They  show  the  ability  to  use  participative  management  or 
other  approaches,  depending  on  the  situation. 

4.  They  show  a  willingness  to  be  accountable  for  results. 
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5.  They  use  two-way  communication. 

6.  They  use  group  methods  and  have  interpersonal  skills. 

7.  They  trust. 

To  the  extent  that  such  a  social  environment  can  be  designed-in  to 
new  process  designs,  an  effective  participative  management 
philosophy  can  contribute  to  new  process  success. 


4.5.3.  Case  Study  Example 


CSK  decided  to  integrate  a  series  of  automated  tools  (enabling 
technologies)  within  product  design  activities,  including: 

•  client/server  technology  -  to  allow  for  local  design  and 
review  of  information,  but  with  centralized  storage  and 
maintenance  of  design  results 

•  standardization  of  product  tools  from  a  single  source  - 
separate  tools  provided  by  a  single  supplier  offering  a  highly 
integrated  infrastructure 

•  Computer  Aided  Design  (CAD)  -  CAD  tools  improved  the 
efficiency  of  designers  in  establishing  designs  which  meet 
specifications  and  can  be  manufactured  at  a  minimum  cost 
and  risk 

•  network  communications  -  common  network  protocols 
(TCP/IP)  were  used  in  order  to  establish  clean 
communication  paths  between  each  department  workstation 

•  document  management  -  tools  were  utilized  which  provided 
document  management  support,  including  elements  of 
configuration  management 


As  previously  mentioned,  the  product  design  activity  was  selected 
for  initial  redesign  due  to  the  criticality  in  delivery  of  reliable 
customer  solutions,  and  the  fact  that  the  foundation  of  the  design 
activity  is  shared  by  other  processes.  CSK  expects,  and  has  set 
targets  for,  increased  customer  demand  over  the  next  five  years, 
which  would  effectively  double  the  staff  size  without 
reengineering. 
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4.5.3.I.  New  Design  Concept  Overview 


Figure  4.5-10  provides  an  overview  of  the  flow  of  information 
within  the  new  CSK  product  design  activity.  Workstations  consist 
of  Pentium  based  personal  computers  which  are  connected  on  a 
Windows  NT  client/server  network. 


Note:  P&ID  =  Piping  and  Instrumentation  Diagram 


Intelligent 

P&ID 


Instrumentation 
&  Sizing  Cjjg 


3-D 

Physical 

Design 


Purchasing 


Integrated 

Design 

Database 


Electrical 

Design 


Intelligent  P&ID:  Initial  P&ID  information  is  extracted  from  proposal  efforts  and  used  to  generate 
an  electronic  P&ID  Diagram,  with  key  unit  design  components  identified  for  engineering  selection. 
Non-key  components  are  made  available  to  purchasing  for  immediate  order. 

Instrumentation  &  Sizing:  Engineering  staff  utilize  P&ID  diagrams  to  carefully  establish  sizes 
and  instrumentation  details  such  as  ranges  and  setpoints.  Results  are  passed  back  for  P&ID  use  in 
generating  further  definition  of  the  project  bill  of  materials. 

3-D  Physical  Design:  Designers  lay  out  the  design  of  the  physical  skids  with  information  imported 
from  the  intelligent  P&ID.  3-D  design  improves  understanding  of  physical  design  characteristics 
with  respect  to  manufacturing  and  shipping.  3-D  Drawings  are  verified  by  engineering  and  used  to 
identify  remaining  materials  for  purchase. 

Electrical  Design:  Engineering  and  design  work  together  to  establish  electrical  design  diagrams, 
including  one  line  diagrams  for  motors  and  control  panels,  and  PLC  logic  diagrams  for  PLC  wiring 
and  programming. 

Purchasing:  Purchasing  is  aware  of  all  required  components  immediately  upon  approval.  Since 
CSK  holds  very  little  inventory,  Just-In-Time  (JIT)  purchasing  and  suppliers  are  key  elements  of 
the  overall  process  design. 


Figure  4.5-10.  CSK  Example  -  Product  Design  Activity  Overview 
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4.5.3.2.  As-Is  Activity  ModelView 

An  activity  model  of  a  small  portion  of  the  CSK  production 
process  identified  as  " Construct  &  Deliver  Customer  Solution"  is 
shown  in  Figure  4.5-10.  This  simplified  example  illustrates  the 
large  emphasis  on  manual  activities  required  to  solicit  supplier  bids 
and  create  the  resulting  purchase  order.  The  existing  activity  set 
(activities  1-7)  in  this  example  consumed  (on  the  average)  102 
labor  hours  from  start  to  finish  to  produce  a  200  component 
project.  Both  enterprise  and  process  based  teams  had  placed 
emphasis  on  reducing  the  cycle  time  relating  to  this  activity  set  in 
order  to  acquire  supplier  parts  in  a  more  timely  manner,  process 
more  projects  with  the  same  number  of  staff,  and  to  provide  more 
accurate  information  to  suppliers. 


Figure  4.5-11.  CSK  Example  -  "As-Is"  Activity  Set 
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4.5.3.3.  To-Be  Activity  Model  View 

After  CSK  completed  reengineering  of  the  same  activity  set,  the 
design  illustrated  in  Figure  4.5-12  resulted.  By  integrating  access 
to  data  in  a  non-redundant  manner,  CSK  is  able  to  instantly  reuse 
information  gathered  and  stored  by  previous  activities  with  little  or 
no  time  delays.  For  example,  the  component  lists  stored  during 
activities  supporting  creation  of  3D  drawings  and  Piping  and 
Instrumentation  Diagrams  (P&IDs)  are  instantly  available  to 
activities  relating  to  soliciting  supplier  bids.  As  a  result,  the  new 
process  design  reduced  the  overall  labor  time  to  complete  this 
activity  set  from  102  total  hours  to  23  total  hours.  The  new  process 
design  results  aligned  directly  with  CSK's  goal  of  not  expanding 
staff,  while  increase  sales  volume.  As  implemented,  the  new 
design  can  support  approximately  four  times  the  workflow  with  the 
same  number  of  staff. 


Figure  4.5-10.  CSK  Example  -  "To-Be"  Activity  Set 
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4.5.3.4.  As-Is  vs.  To-Be  Process  Evaluation 

A  more  detailed  breakdown  of  the  average  number  of  hours 
associated  with  each  activity  shown  in  Figure  4.5-11  and  Figure 
4.5-12  respectively  is  provided  in  the  following  table.  The  table 
provides  a  comparison  of  "as-is"  and  "to-be"  activity  cycle  times 
along  with  the  average  number  of  hours  associated  with  each.  In 
addition  to  the  time  savings,  CSK  also  noted  less  errors  in  bid 
requests  and  purchase  orders  by  using  common  data,  reducing 
additional  costs  and  time  associated  with  wasted  effort. 


Activity#.  Name 

As-is 

To-Be 

1.  Summarize  Components 

10  hrs 

0  hr 

2.  Select  Key  Components 

2  hrs 

2  hrs 

3.  Create  &  Approve  Bid  Form 

33  hrs 

0  hr 

4.  Send  Bid  Form  to  Supplier 

20  hrs 

0  hr 

5.  Receive  and  Log  Bids 

11  hrs 

11  hrs 

6.  Select  Supplier 

1  hr 

1  hr 

7.  Create  Purchase  Order 

25  hrs 

1  hr 

Totals 

102  hrs 

23  hrs 

Table  4.5-1.  CSK  Example  -  "As-is"  vs.  "To-Be"  Comparison 
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Where  Am  I? 


At  this  stage,  several  elements  of  the  reengineering  effort  are 
complete,  including: 

•  a  new  design  for  a  business  process  (technical  and  social) 
has  been  selected 

•  a  Process  Action  Team  (PAT)  has  been  empowered  to 
complete  the  process  transformation 

•  business  goals  and  targets  have  been  properly  communicated 
to  PAT  members,  providing  further  guidance  to  the 
transformation  effort 

This  chapter  addresses  both  the  transformation  of  the  existing  or 
"as-is"  process  into  the  new  or  "to-be"  process  design  and  the 
controlled  evolution  of  the  process  once  the  transformation  efforts 
are  complete. 


5.1.  planning  &  Executing  Transformation 

Before  discussing  further  issues  relating  to  process  transformation, 
the  relationship  between  transformation  and  evolution  needs  to  be 
better  understood. 

Evolution  represents  the  gradual  change  of  a  process  over  time.  In 
general,  evolutionary  efforts  are  not  considered  radical  and  do  not 
represent  the  high  risk  and/or  high  potential  breakthrough 
associated  with  transformation. 

As  mentioned  in  Chapter  1,  the  term  Legacy  Business  Processes 
refers  to  processes  (consisting  of  people,  systems,  and 
organizational  structure)  which  have  been  institutionalized  within  a 
business.  The  objective  of  controlled  process  evolution  (described 
in  Section  5.2)  is  to  ensure  that  evolutionary  activities  migrate 
legacy  business  processes  towards  business  goals  and  targets. 

What  is  Transformation  Conversely,  transformation  represents  the  implementation  of  more 

fundamental  and  radical  changes  to  a  business  process,  potentially 
resulting  in  a  total  process  redesign.  With  this  in  mind, 
transformation  represents  a  form  of  rapid  evolution,  speeding 
evolution  to  reach  business  targets  in  a  faster  fashion. 
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5.1.1.  Preparing  the  Process  for  Change 

Regardless  of  the  complexity  of  the  process  design  change,  several 
common  areas  should  be  addressed  when  planning  transformation, 
including: 

•  education  and  training 

•  procedures 

•  infrastructures 

Each  of  these  areas  are  discussed  in  further  detail  in  the  following 
subsections. 

5.1.1.1.  Education  and  Training 

Process  workers  must  be  considered  part  of  a  process  improvement 
team,  and  must  be  educated  in  the  new  roles  and  responsibilities 
assigned  to  improve  process  workflow.  While  this  information  may 
be  provided  in  written  form,  an  open  forum  for  discussion  is 
recommended  in  order  to  share  issues  relating  to  the  proposed  new 
design.  Such  open  discussions  will  often  lead  to  two-way 
education,  improving  the  team  knowledge  of  new  design 
implications  and  the  process  workers'  understanding  of  the  desired 
goals  and  expectations. 

Part  of  the  educational  process  is  to  explain  the  concept  of  a 
learning  organization.  Since  each  process  worker  will  work  as  part 
of  a  team  to  improve  process  workflow,  learning  and  adapting  will 
be  a  natural  part  of  process  evolution.  New  changes  resulting  from 
process  redesign  need  not  be  considered  permanent,  just  the  next 
evolutionary  stage  in  the  life  of  a  process. 

New  process  designs  will  often  require  training  of  staff  in  order  to 
allow  for  smooth  transition  into  new  roles  and  responsibilities. 
New  procedures  (written)  will  help  staff  in  resolving  problems,  but 
training  in  new  procedures  will  show  process  workers  how  to 
perform  new  processes  more  efficiently.  Such  training  should 
include  the  proper  use  of  new  equipment,  computer  systems,  and 
other  workflow-enabling  interfaces. 
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5.1. 1.2.  Procedures 

Documentation  of  procedures  will  aide  in  process  worker 
education  and  training,  as  well  as  ensure  clarity  in  the  definition  of 
roles  and  responsibilities.  Writing  down  the  more  detailed 
procedures  to  complete  a  task  will  often  uncover  additional  areas 
for  process  improvement. 

Procedures  should  be  updated  on  a  continuous  basis,  this  process 
must  be  viewed  as  value-added,  not  wasted  paperwork,  to  both 
process  workers  and  management.  A  common  way  of  improving 
process  procedures  is  to  empower  process  workers  as  the 
maintainers  of  the  procedures. 


5. 1.1.3.  Infrastructures 

The  transformation  effort  should  not  be  started  without  the  tools 
necessary  to  carry  the  effort  forward.  Completing  education, 
training,  and  associated  procedures  is  difficult  without  the 
infrastructure  in  place  to  demonstrate  and  facilitate  process 
workers'  understanding.  Infrastructures  may  include  office  space, 
computers,  new  equipment,  software,  teams,  organizational 
hierarchy,  etc. 

5. 1.2.  PHASING  PROCESS  TRANSFORMATION 

Process  transformation  will  often  be  completed  in  a  series  of 
phases  over  time.  No  "magic  formula"  is  available  to  balance  all  of 
the  factors  affecting  how  to  implement  the  proposed  design  in 
phases.  Clear  priorities  often  emerge  during  the  process  modeling, 
evaluation,  and  redesign  steps  performed  to  reach  this  stage.  The 
following  paragraphs  discuss  issues  affecting  the  prioritization  and 
phasing  of  process  transformation. 

5. 1.2.1.  Management  Priorities 

The  process  sponsor  (source  of  funds)  or  the  system  users  often 
will  have  predefined,  high-priority  problem  areas  within  the 
process  purview.  Such  priorities  may  drive  the  transformation 
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process  since  they  may  have  been  the  incentive  for  originating 
reengineering  efforts. 

Dictated  priorities  can  scramble  an  otherwise  effective  plan.  Where 
possible,  those  who  plan  transformation  must  inform  management 
when  dictated  priorities  are  not  aligned  with  common  sense 
process-based  priorities. 

5, 1.2.2.  Sequential/Functional  Precedence 

Interrelationships  between  processing  activities  may  indicate  a 
sequence  for  phased  development.  For  example,  one  activity  or  set 
of  activities  may  gather  and  store  data  which  is  recalled  later  by 
another,  perhaps  to  create  summary-level  reports.  The  first  module 
(set  of  activities)  must  be  in  place  and  gathering  data  before  the 
second  can  perform  its  intended  function. 

As  a  general  rule,  transformation  follows  the  workflow  through  the 
activity  set  identified  for  change.  This  does  not  imply  that  changes 
must  occur  in  every  activity,  starting  at  the  first,  throughout  the 
process  model.  Often,  an  activity  set  (a  series  of  activities)  within 
the  process  can  be  identified  and  prioritized  for  immediate  change. 


5. 1.2.3.  Early  Payback  -  Prototype  or  Revolutionary  Implementation 

In  initial  reengineering  efforts,  it  is  good  for  team  morale  and 
confidence  to  show  results  quickly,  at  least  in  a  limited  area 
(prototype  implementation).  Be  aware  that  attempting  quick 
success  means  risking  quick  failure.  Conversely,  attempting  quick 
success  (revolutionary  implementation)  may  be  the  only  way  to 
achieve  the  desired  business  breakthroughs.  Therefore,  it  is  critical 
that  the  reengineering  team  select  activity  sets  and  phase 
implementation-based  on  the  speed  of  change  required  by  business 
goals  and  targets. 


"Trail  Blazing" 
Prototype 


Rapidly  implementing  the  new  design  of  an  activity  set  quickly 
represents  a  form  of  a  transformation  prototype.  Team  members 
should  ensure  that  the  prototype  reaps  the  benefits  common  to  this 
form  of " trailblazing" ,  such  as: 
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•  confirming  the  transformation  approach  and  identifying 
potential  "speed-bumps"  to  change 

•  creating  standards  and  examples  for  further  process  change 

•  serving  as  a  yardstick  for  the  estimation  of  resources  for 
transformation  of  later  activities 

•  building  consensus  and  momentum  for  further  reengineering 

A  brief  discussion  relating  to  the  use  of  prototypes  as  a  proof  of 
concept  for  new  process  designs  is  provided  in  Section  4.5. 1.7. 


5. 1.2.4.  Shared  Activities 

Activities  within  a  business  enterprise  may  be  shared  by  many 
processes.  For  example,  a  product  design  activity  may  be  shared  by 
a  process  supporting: 

•  proposal  development 

•  design  for  production 

•  research  and  development 

Therefore,  transformation  of  shared  activities  may  provide 
dramatic  improvements  to  the  overall  business  by  improving 
several  processes  at  once.  Those  planning  transformation  should 
consider  addressing  shared  activities  early  in  the  implementation. 

5.1.2.5.  Non-Developmental  Items  (NDIs) 

Another  way  to  achieve  early  payback  is  to  identify  an  activity  set 
for  which  off-the-shelf,  commercial  products  (software  packages, 
processing  machines,  workstations,  etc.)  will  fulfill  design 
requirements. 

Teams  should  consider  placement  of  Non-Developmental  Items 
(NDIs)  early  in  the  schedule  to  confirm  that  further  development  is 
not  required,  and  reduce  the  scope  of  the  internal  development 
efforts.  Care  should  be  taken  to  ensure  that  a  given  NDI  meets  the 
critical  design  requirements  necessary  to  achieve  the  desired 
process  change. 
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A  brief  discussion  relating  to  the  use  of  off-the-shelf  solutions 
within  new  process  designs  is  provided  in  Section  4.5. 1.6. 


5. 1.2.6.  Criticality,  Performance,  &  Resource  Constraints 

If  unlimited  resources  were  available,  development  on  all  activities 
could  begin  immediately.  In  the  real  world,  management  sets 
priorities  for  transformation  and  allocate  resources  accordingly. 
Activity  sets  remaining  after  the  above  factors  are  considered  must 
be  prioritized  based  on  performance  and  criticality  criteria  in  a 
similar  manner  that  business  processes  were  assessed  in  early 
reengineering  stages  (see  Chapter  3). 

In  general  terms,  an  activity  is  studied  sooner  if  the  function  is 
more  critical  to  the  business  goals  and  targets  and  if  the  activity 
requires  a  high  degree  of  change  to  meet  business  targets.  As  an 
example,  a  wholesaler  may  choose  to  limp  along  with  an 
inefficient,  but  working,  manual  payroll  system  and  concentrate 
first  on  improving  shipping  response  times.  Compared  to  shipping, 
the  payroll  function  is  peripheral  to  the  business  mission. 
However,  if  expanding  employment  has  taxed  payroll  to  the  point 
where  employees  are  not  being  paid  on  time,  the  wholesaler  would 
probably  choose  to  overhaul  payroll  first.  In  this  case,  the 
performance  disparity  in  payroll  outweighs  the  relative  mission 
importance  of  quick  shipping  response. 

5. 1.2.7.  Traditional  Prioritization  by  Cost  Savings 

Priorities  have  traditionally  been  set  by  estimating  cost  savings  for 
each  improved  activity.  However,  cost  savings  are  notoriously 
difficult  to  estimate  accurately.  The  analysis  resulting  from  both 
throughput  and  dynamic  modeling  and  simulation  can  be  used  to 
predict  potential  cost  savings  by  performing  cost  trade-off  analysis 
on  each  change  recommended. 

Activity  Based  Costing  (ABC)  is  another  useful  technique  for 
determining  priority  based  on  activity  cost.  See  Section  4.4.4  for 
more  information  on  ABC. 
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5.1.3.  Creating  the  transformation  Plan 

The  constraints  associated  with  any  business,  including  the  staff 
available  to  execute  process  changes  and  the  dollars  available  to 
purchase  new  equipment  and  fund  process  changes,  often  will  limit 
the  speed  of  the  transformation  effort.  To  reap  the  benefits  of 
reengineering,  changes  must  be  made  as  quickly  as  possible  within 
the  known  constraints. 


Automating  Project 
Planning  and  Tracking 


Record  Transformation 
Plan 


Small  organizations  may  execute  changes  in  near  real-time  with 
results  seen  in  one  to  three  months,  while  larger  organizations  may 
take  one  to  two  years  to  complete  the  transformation  effort  for  key 
processes. 

Regardless  of  the  magnitude,  a  transformation  plan  is  established 
as  a  roadmap.  As  a  minimum,  this  plan  will  outline  the  following: 

•  phasing  of  changes  to  occur  within  a  process 

•  the  resources  necessary  to  complete  the  change 

•  the  planned  efforts  to  train  and  educate  process  workers 

Key  milestones  within  the  plan  should  be  highlighted  to  show 
where  and  when  critical  features  of  the  new  business  process 
design  have  been  implemented. 

The  complexity  of  large  reengineering  projects  demands  that  the 
management  process  be  as  effective  and  efficient  as  the  process 
management  seeks  to  develop.  An  automated  project  planning  tool 
is  recommended  for  creation  and  maintenance  of  the  plans  guiding 
the  transformation  effort. 

The  resulting  transformation  plan  is  incorporated  into  the  Process 
Management  Notebook.  All  ERT,  PAT  members,  and  process 
workers  have  access  to  the  PMN  to  reduce  duplication  of  effort  and 
increase  common  process  knowledge. 
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Reengineering  team  members  from  CSK  established  an  aggressive 
plan  for  transformation  of  process  activities.  Activities  with  similar 
requirements  were  grouped  into  activity  sets  and  organized 
according  to  order  of  precedence  and  degree  of  sharing  amongst 
value  stream  processes.  A  brief  overview  of  the  CSK  plan 
(illustrated  in  Figure  5.1-1)  included  the  following: 

•  Infrastructure  (COTS  Acquisition)  -  CSK  reviewed 
automated  solutions  relating  to  their  complex  engineering 
and  design  activity  needs  and  purchased  a  suite  of  products 
from  a  single  commercial  supplier.  This  action  was  placed 
early  in  the  transformation  schedule  to  ensure  that  the 
infrastructure  was  in  place  to  effectively  support  the 
transformation  effort. 

•  Intelligent  P&ID.  Electrics,  and  Instrumentation  - 
Automated  tools  supporting  fundamental  engineering  and 
design  activities  were  implemented  over  a  eight  to  ten  week 
timeframe.  First,  tools  were  deployed  in  a  localized  fashion; 
then  temporary  bridges  were  established  to  foster  transparent 
communication  of  information  from  station  to  station. 

•  Integrated  Network  and  Database  Design  -  CSK 
implemented  procedures  ,  tools  and  data  into  an  integrated, 
shared  office  environment,  eliminating  temporary  bridges 
required  for  station  to  station  communications.  Integration 
was  completed  over  a  three  month  timeframe. 

•  3-D  Computer  Aided  Design  -  CSK  integrated  tools 
supporting  the  critical  3-D  design  activities,  supporting  both 
proposal  and  production  oriented  processes.  Complete 
implementation,  including  training  and  testing  of  the  3-D 
design  solution,  was  planned  for  a  three  to  four  month 
timeframe. 

•  Purchasing  -  Since  engineering  and  design  activities  lead  to 
selection  of  components  for  purchase,  ancillary  activities 
relating  to  component  purchasing  were  also  targeted  for 
redesign.  CSK  planned  for  a  three  to  four  month 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


CHAPTER  5.  TRANSFORMATION  AND  EVOLUTION 


Page  149 


implementation  of  purchasing,  after  transformation  of 
engineering  and  design  activities  was  complete. 

•  Integrated  Document  and  Workflow  Management  -  To 
complete  the  transformation  effort,  CSK  controlled 
workflow  through  the  enterprise  processes  by  implementing 
a  suite  of  document  and  workflow  management  tools  which 
allowed  for  complete  integration  and  traceability  of 
engineering  and  design  activities,  from  product  concept 
through  customer  delivery.  Automated  workflow  tools 
allowed  for  the  establishment  of  business  policies  for 
documents  contributing  to  project  completion. 
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Figure  5.1-1.  CSK  Example  -  Process  Transformation  Plan 


Revolutionary  CSK  chose  to  implement  major  design  transformations  on  the 

Implementation  .  .  ,  . 

largest  project  in  company  history.  This  revolutionary  approach 

forced  the  speed  of  transformation  and  resulted  in  improved 

teamwork  and  customer  product  quality.  As  a  result,  CSK  has 

successfully  completed  the  first  seven  months  of  their 

transformation  plan  and  is  currently  working  to  implement  new 

purchasing  designs.  In  addition,  CSK  became  equipped  to  further 

meet  the  business  targets  for  excellence  established  in  Chapter  2  of 

this  document. 
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CSK  targets  for  excellence  are  outlined  in  Section  2.3.6. 

5.1.4.  transitioning  to  process  Evolution 

Transformation  signifies  the  last  step  in  the  reengineering  life 
cycle.  Once  process  transformation  is  complete,  the  less  radical 
efforts  associated  with  evolution  immediately  begin.  Process 
evolution  continues  until  the  business  process  design  is  revisited 
(assessed)  and  determined  to  be  in  need  of  further  reengineering. 
This  continuous  process  of  reengineering  and  evolution  occurs 
throughout  the  life  of  a  business  process,  as  illustrated  in  Figure 
5.1-2. 


Figure  5.1-2.  Reengineering  -  Evolution  cycle. 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


CHAPTER  5.  TRANSFORMATION  AND  EVOLUTION 


Page  151 


5.2.  CONTROLLED  PROCESS  EVOLUTION 


As  described  previously  in  Chapter  1  and  shown  in  Figure  5.2-1, 
business  processes  are  always  in  one  of  four  phases  of  the  Process 
Management  Life  Cycle  (PMLC). 


Figure  5.2-1.  PMLC  Overview 


A  process  in  evolution  is  one  which  has  previously  been 
engineered  or  reengineered,  yielding  the  existing  institutionalized 
process  design  (referred  to  as  a  legacy  process).  The  objective  is  to 
provide  a  means  by  which  a  legacy  process  is  gradually  improved 
through  Controlled  Process  Evolution. 


. ..  . JW  „  ..  .. 

in  which  continuous  process  improvements  are  utilized 
to  evolve  processes  in  a  value  added  manner 
respect  to  business  goals. 


Evolving  a  business  process  in  a  continuous,  yet  controlled 
manner,  may  limit  the  need  for  later  reengineering  of  a  radical 
nature. 


5.2.1.  The  Continuous  Improvement  Cycle 

In  the  1920s,  the  work  of  Dr.  Shewhart  resulted  in  the  four-step 
scientific  approach  to  continual  process  improvement  shown  in 
Figure  5.2-2.  The  resulting  cycle  initially  gained  recognition  from 
the  works  of  Dr.  Deming  starting  in  the  1950s  and  is  still  accepted 
as  a  fundamental  approach  today.  The  Plan-Do-Check-Act 
Continual  Improvement  Cycle  is  also  referred  to  as  the: 

•  Shewhart  Cycle 

•  Deming  Cycle 
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Plan 


Do 


Check 


Act 


•  Deming  Wheel 

•  P-D-C-A 


A  brief  overview  of  each  step  is  provided  in  the  following 
paragraphs. 

The  primary  key  to  successful  business  process  evolution  is 
planning.  Changes  to  the  process  must  not  be  made  arbitrarily  or 
without  scrutiny.  Each  process  change  identified  must  represent  a 
quantifiable  improvement  to  a  business  process.  The  majority  of 
the  Seven  Management  Tools  described  in  Section  5.3.3  of  this 
document  may  be  used  to  organize  ideas  and  evaluate  process 
improvement  plans.  It  should  be  noted  that  such  tools  are  not  a 
substitute  for  sound  "common  sense"  thinking. 

A  plan  has  little  value  if  it  is  not  executed.  The  purpose  of  this  step 
is  to  execute  the  plan  previously  generated. 

During  this  step,  the  business  process  is  monitored  and  evaluated 
to  determine  the  impact  of  changes  made.  Section  5.3  of  this 
document  provides  an  overview  of  common  TQM  tools  used  to 
evaluate  process  characteristics  and  propose  potential  actions. 

The  Act  step  represents  a  chance  to  continue  execution  of  the 
existing  plan  if  the  desired  process  improvement  goals  were 
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achieved  or  adjust  the  plan  based  on  the  impact  of  previous 
changes  made. 

5.2.2.  Evolving  Towards  Process  Maturity 

Controlled  Process  Evolution  combined  with  reengineering  will 
eventually  lead  to  more  mature  business  processes.  With  each 
continuous  improvement  cycle,  the  knowledge  of  a  process 
intricacies,  capabilities,  and  health  increases. 


Time 


Figure  5.2-3.  Business  Process  Maturity 

The  greater  the  process  maturity,  the  greater  the  following 
attributes: 

•  process  understanding 

•  process  documentation  and  models 

•  process  vision 

•  process  benchmarks 

•  process  metrics  and  statistics 

•  process  simulation  and  experiments 
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•  process  control 

•  process  achievement  of  goals/targets 

The  more  mature  the  business  process,  the  more  detailed  the 
analysis  required  to  improve  performance. 


5.2.3.  Culture  &  Teamwork 


As  described  in  Chapter  2,  successful  reengineering  requires 
communication  and  teamwork  in  both  a  top-down  and  bottom-up 
manner.  Enterprise  level  teams  must  continue  to  communicate  the 
business  mission,  goals,  and  targets  to  operations  level  teams 
(commonly  consisting  of  Process  Action  Teams).  In  return,  PATs 
evolve  business  processes  towards  desired  goals,  improved  process 
workflow,  and  provide  continuous  feedback  to  enterprise  level 
teams.  This  integrated  team  environment  (illustrated  in  Figure  5.2- 
4)  must  be  emphasized  throughout  all  stages  of  reengineering  and 
evolution. 


Enterprise  Level 


Business  Level 


Operations  Level 


Figure  5.2-4.  Top  Down  -  Bottom  Up  Team  Implementation 
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5.3.  The  tools  of  Transformation  and  Evolution 

There  are  a  variety  of  tools  typically  used  as  part  of  process 
improvement  efforts  to  aid  in  process  transformation  and 
evolution.  A  brief  overview  of  commonly  used  tools  is  provided 
within  this  section.  Readers  should  understand  that  TQM  is  not  a 
collection  of  tools,  but  a  philosophy.  Many  of  the  tools  identified 
have  a  long  history  and  their  applications  are  not  limited  to  TQM 
and  BPR.  For  further  details  relating  to  the  description  and 
application  of  the  tools  identified,  readers  should  review  the  "TQM 
Toolkit",  also  published  by  the  Reliability  Analysis  Center. 


5.3.1.  Seven  Basic  Tools 

A  leading  Japanese  process  improvement  guru,  Kaoru  Ishikawa, 
contended  that  95%  of  organization  problems  can  be  solved  using 
seven  basic  tools  including: 

•  Flowcharts 

•  Ishikawa  Diagrams 

•  Checklists 

•  Pareto  Charts 

•  Histograms 

•  Scattergrams 

•  Control  charts 

5.3.1.1.  Flow  Charts 

Flow  charts  describe  a  process  as  a  means  to  understanding  it.  A 
flow  chart  is  often  the  first  step  taken  by  a  process  improvement 
team.  Flow  charts  are  a  logical  starting  point  for  improvements 
since  they  center  around  process  workflow.  Flow  charts  often 
reveal  flaws  and/or  hidden  gaps  in  processes  commonly  unknown 
to  team  members.  A  flow  chart  can  be  as  simple  or  complex  as 
needed  to  understand  the  process. 


Reliability  Analysis  Center  •  P.O.  Box  4700  "  Rome,  NY  13440-4700  •  (315)  337-0900 


Page  156 


CHAPTER  5.  TRANSFORMATION  AND  EVOLUTION 


Greater  details  of  process  modeling  (using  basic  flowchart 
concepts)  are  provided  in  Chapter  4. 


5.3.I.2.  Ishikawa  Diagrams 

Ishikawa  Diagrams  or  "fishbone"  charts  are  named  after  their 
inventor,  Kaoru  Ishikawa.  Also  referred  to  as  cause  and  effect 
diagrams,  the  purpose  of  the  fishbone  diagram  is  to  identify  the 
factors  resulting  in  an  effect  of  interest.  The  area  of  interest  may  be 
a  problem  to  be  solved  or  an  objective  to  be  achieved.  The 
following  figure  illustrates  the  common  structure  of  a  Ishikawa 
diagram. 

FACTOR  FACTOR  FACTOR 


Figure  5.3-1.  Ishikawa  Diagram 


Process  factors  are  commonly  identified  by  people  familiar  with 
the  process  whose  inputs  are  obtained  by  interviews  or  by 
brainstorming  methods.  Each  factor  may  then  be  subdivided  as 
necessary. 

The  Ishikawa  Diagram  is  useful  in  any  situation  where  it  is  critical 
to  determine  the  causes  of  a  problem  or  how  to  meet  a  desired 
goal. 

5.3.1. 3.  Checklists 

Checklists  represent  a  means  for  collecting  data  to  provide 
quantifiable  information  relating  to  process  activities.  Suitable 
checklists  establish  clear,  mutually  exclusive  categories. 


5.3.1. 4.  Pareto  Charts 

A  Pareto  Chart,  named  after  Alfredo  Pareto,  is  used  to  illustrate  the 
relative  importance  of  key  aspects/characteristics  of  a  process. 
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Such  a  chart  is  commonly  used  to  isolate  the  80-20  principle, 
where  80%  of  the  problems  are  caused  by  20%  of  the  activities. 
The  chart  may  be  used  with  or  without  a  line  of  cumulative  value 
added  to  the  bars  as  shown  in  the  following  figure. 


#  of  Customer 
Complaints 


Workshift 


Figure  5.3-2.  Pareto  Chart  Example 


Pareto  Charts  can  be  nested  (i.e.,  the  data  from  one  bar  on  the  chart 
used  to  create  another  Pareto  chart  with  more  detailed  information) 
or  stratified,  which  results  in  creating  a  set  of  Pareto  Charts  for  the 
same  data  with  different  categories/factors.  Figure  5.3-3  illustrates 
the  number  of  customer  complaints  across  several  different  sets  of 
categories. 


#  of  Customer 

#  of  Customer 

Complaints 

Complaints 

L 

3 

2 

1 

2 

1 

3 

Shift  Producing  Complaint  Type  of  Complaint 


Figure  5.3-3.  Stratification  of  Pareto  Charts 

Analysis  of  this  information  may  indicate  that  the  number  of 
highly  critical  customer  complaints  occur  during  a  specific  shift  or 
that  the  majority  of  complaints  received  are  of  a  specific  type. 
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Such  information  is  useful  when  reviewing  potential  actions  for 
process  improvement. 


5.3.1. 5.  Histograms 


A  histogram  is  another  form  of  chart  used  to  display  the  variation 
in  a  set  of  data.  A  histogram  is  similar  in  nature  to  a  Pareto  Chart, 
but  focuses  on  a  relative  comparison  of  continuous  variables  as 
shown  in  Figure  5.3-4. 


#  of  Customer 
Complaints 


Type  of  Complaint 


Figure  5.3-4.  Histogram  Example 


5.3.I.6.  Scattergrams 

Scattergrams  are  useful  in  determining  the  degree  of  association  or 
relationship  between  two  variables.  Strong  relationships  would 
result  in  a  linear  pattern  of  data  points,  while  weak  relationships 
would  result  in  a  circular,  more  random  pattern  as  illustrated  in 
Figure  5.3-5. 

Strong  Weak 

Relationship  Relationship 

/  \ 

o  0  o  o 

oo 
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_  o°  o 

Parameter  ° 

A  0  o 


Parameter  B  Parameter  B 


Figure  5.3-5.  Scattergram  Examples 


Parameter 

A 
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5.3.I.7.  Control  Charts 

Control  charts  provide  a  means  of  assessing  process  variability. 
Generally,  control  charts  require  the  use  of  statistical  equations  to 
derive  a  mean  and  standard  deviation  for  the  process  in  order  to 
establish  upper  and  lower  control  limits. 

Data  are  usually  plotted  in  consecutive  order  on  the  horizontal  axis, 
with  lines  drawn  from  point  to  point.  The  process  is  assumed  to  be 
in  control  (stable)  if  the  plotted  points  fall  between  the  predefined 
control  limits  and  the  points  vary  randomly.  Points  which  fall 
outside  of  the  control  limits  indicate  the  process  is  not  in  control, 
and  therefore  requires  further  investigation  to  identify  the  variation 
source.  Figure  5.3-6  shows  a  typical  view  of  a  control  chart  for  an 
unstable  process. 


Indicates  Process 
Out  of  Control 


Time  --> 


Figure  5.3-6.  Control  Chart  Example 


5.3.2.  Other  Simple  Tools 

Besides  the  seven  basic  tools,  there  are  many  other  simple  tools 
which  can  be  useful  in  analyzing  processes  including  those 
outlined  in  the  following  subsections. 


5.3.2. 1.  The  Force  Field 

A  force  field  diagram  shows  factors  favoring  and  opposing  an  goal 
of  interest.  Ishikawa  charts  can  be  used  to  develop  a 
comprehensive  list  of  factors  for  integration  into  a  force  field 
diagram.  There  are  several  variations  in  force  field  diagrams,  a 
simplified  example  is  provided  in  Figure  5.3-7  showing  the  forces 
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opposing  a  desired  outcome  pushing  down  against  counterforces 
factoring  the  goal.  The  idea  is  to  identify  which  opposing  forces 
are  stronger  than  their  counterforces. 

FORCES  OPPOSING  EVENT  OF  INTEREST 
FORCE  A  FORCE B  ...  FORCE  N 


COUNTERFORCE  A  COUNTERFORCE  B  ...  COUNTERFORCE  N 

^ - T - 

Factor  1 

FORCES  FOR  EVENT  OF  INTEREST 


Figure  5.3-7.  Force  Field  Diagram  Example 


5.3.I.2.  The  "Measles"  Chart 

The  "measles"  chart  represents  a  graphical  form  of  a  check  list. 
The  measles  chart  is  often  preferable  to  tabular  forms  since 
graphical  forms  often  highlight  missing  information  and/or  data 
collection  gaps.  A  Measles  Chart  example  is  provided  in  Figure 
5.3-8. 
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5.3.2.3.  Benchmarking 

Benchmarking  is  the  systematic  comparison  of  a  company's 
performance  against  its  competitors  and  against  the  leaders  in  and 
out  of  the  industry. 

Greater  detail  relating  to  the  topic  of  benchmarking  is  provided  in 
Section  4.4.5  of  this  document. 

5.3.2.4.  Cycle  Time  Management  (CTM) 

A  common  goal  is  the  reduction  of  cycle  time.  This  can  be  done  by 
using  faster  methods  such  as  automated  assembly  replacing  manual 
or  by  reducing  delays  and  eliminating  operations  that  do  not  add 
value.  The  CTM  chart,  illustrated  in  the  following  figure,  shows  a 
process  with  three  activities. 


Value  added 

activities  1 

A 

2  4 

B 

5 

C 

non-value  added 
activities 

3 

time 

A,B/C  =  process  steps  which  add  value 
1 ,2,4/5  =!  delays  between  process  steps 
3  =  non-value  added  activity 

Figure  5.3-9.  Cycle  Time  Management  Chart 

The  process  may  be  improved  by: 

•  shortening  the  activity  cycle  time 

•  reducing  the  delays  between  process  steps 

•  eliminating  or  reducing  non- value  added  activities 

A  lower  cycle  time  permits  faster  response  to  customer  needs  and 
reduces  the  number  of  items  in  process. 

5.3.2.5.  Multi-Vari  Charts 

Multi- vari  charts  are  a  simple  method  of  tracking  variation  within  a 
part,  variation  between  parts,  and  variation  over  time.  Such  charts 
often  depict  a  sample  of  parts/products  on  the  horizontal  axis  with 
the  parameter  under  study  on  the  vertical  axis  as  shown  in  Figure 
5.3-10. 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


Page  162 


CHAPTER  5.  TRANSFORMATION  AND  EVOLUTION 


SAMPLES 

LOT  1  LOT  2  LOT  3 


Figure  5.3-10.  Multi-Vari  Chart 


5.3.2.6.  The  Five  Whys? 

The  simplest  tool  of  all  for  improving  processes  is  the  question 
"why?"  Ishikawa  describes  a  process  he  calls  "the  five  whys" 
which  is  simply  the  repetition  of  the  question  until  the  root  cause 
of  a  problem  is  reached.  This  may  take  more  or  less  than  five 
iterations,  but  the  number  is  used  as  an  arbitrary  symbol  of 
repetition. 

5.3.3.  The  Seven  Management  and  Planning  Tools 

The  Seven  Management  and  Planning  Tools,  or  seven  new  QC 
tools ,  were  first  described  in  a  book  published  by  the  Japanese 
Union  of  Scientists  and  Engineers  (JUSE)  in  1979,  edited  by 
Shigeru  Mizuno.  These  tools  represent  mechanisms  by  which 
management  can  plan  and  analyze  business  processes  in  ways  that 
lead  to  quality  improvements.  The  seven  tools  include: 

1.  The  Affinity  Diagram 

2.  The  Relations  Diagram 

3.  The  Tree  Diagram 

4.  Matrix  Analysis 

5.  Matrix  Diagrams 

6.  The  Process  Decision  Program  Chart 

7.  The  Arrow  Diagram 
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A  brief  overview  of  each  of  these  tools  is  described  in  the 
following  subsections. 

5.3.3.I.  The  Affinity  Diagram 

The  Affinity  Diagram  is  commonly  used  as  a  team  thinking  tool  to 
convert  a  random  selection  of  ideas  or  concepts  into  orderly  and 
understandable  groups.  Such  groups  are  generated  by  pairing  ideas 
with  others  based  on  a  feeling  of  affinity  which  Webster's  defines 
as  "a  likeness  based  on  relationship  or  causal  connection" . 

For  example,  a  team  may  generate  a  random  list  of  problems 
associated  with  a  given  process  through  brainstorming  and/or 
interviewing.  The  resulting  list  can  be  organized  using  an  Affinity 
Diagram  to  establish  problem  groups  which  will  be  appropriately 
titled.  A  simple  mechanism  for  implementing  this  approach 
involves  the  use  of  desktop  post-its.  Each  team  member  writes  a 
single  problem  on  each  post-it  and  sticks  it  on  a  wall  or  board.  The 
post-its  are  then  organized  into  groups  and  titled. 


Figure  5.3-11.  Affinity  Diagram 


5.3.3.2.  The  Relations  Diagram 

The  Relations  Diagram,  sometimes  referred  to  as  a 
Interrelationship  DIAGRAM,  illustrates  the  relations  of  factors 
leading  to  a  problem.  The  goal  of  a  Relations  Diagram  is  to 
identify  the  factors  of  importance  and  provide  insight  into  factor 
criticality.  Its  main  value  may  be  in  the  thought  that  goes  into  its 
creation  and  the  iteration  necessary  to  arrive  at  a  meaningful 
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picture.  The  causes  for  the  shipment  of  wrong  items  to  a  firm's 
customers  is  illustrated  in  Figure  5.3-12. 


Figure  5.3-12.  Relations  Diagram  Example 


5.3.3.3.  The  Tree  Diagram 

A  Tree  Diagram  is  created  by  decomposing  a  goal  into  associated 
factors,  which  may  in  turn  be  further  decomposed  into  subfactors. 
Figure  5.3-13  diagrams  the  categories  and  subfactors  discussed  in 
1995  applications  for  the  Malcolm  Baldrige  National  Quality 
Award.  Such  factors  could  be  further  decomposed  in  a  separate 
Tree  Diagram. 
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Senior  executive  leadership 
Management  for  Quality 
Public  responsibility 

Scope  and  management  of  quality  data 

Benchmarking 

Analysis  and  uses  of  data 

Strategic  planning  process 
Quality  and  performance  plans 
Human  resource  management 
Employee  involvement 
Quality  education  and  training 

Performance  measurement  and 
employee  recognition 

Employee  well-being  &  morale 

Design/intro  of  products 
Product/ service  processes 
Business /support  processes 
Quality  assessment 
Supplier  quality 

Product/services  quality 
Business  process /support  service 
Supplier  quality 
Operational  Results 
Customer  relations  management 
Commitment  to  customers 
Determining  satisfaction 
Results 

Comparison  to  competitors 
Future  requirements /expectations 


Figure  5.3-13.  Tree  Diagram  Example:  Malcom  Baldridge  National  Quality  Award 


5.3.3.4.  Matrix  Analysis 

Matrix  Analysis  is  commonly  used  as  part  of  strategic  planning.  A 
similar  approach  was  used  in  Chapter  3  of  this  document  to  review 
candidate  processes  for  reengineering.  In  its  simplest  form  the 
chart  may  be  used  to  compare  the  importance  of  several  problems 
(as  indicated  by  A  through  D  in  Figure  5.3-14)  relative  to  the  need 
for  improvement  to  meet  business  goals. 
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Need  for  Improvement 

54 


C 


A 


1 


3,3 


5 


Importance 


D 


1 


B 


Figure  5.3-14.  Matrix  Analysis  Example 


5.3.3.5.  Matrix  Diagrams  and  Quality  Function  Deployment 

Quality  Function  Deployment  (QFD)  provides  a  comparison  of 
"Whats"  to  "Hows"  along  with  symbols  describing  strength  of 
relationships  between  each.  Applications  of  QFD  can  vary  from  a 
simple  horizontal  and  vertical  axis  matrix  to  the  "House  of 
Quality",  illustrated  in  the  Figure  5.3-15,  which  integrates  priority 
and  criticality  to  the  matrix. 


Figure  5.3-15.  Matrix  Diagram  : House  of  Quality 
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Techniques  such  as  QFD  have  been  found  to  be  effective  in 
assuring  that  the  customers'  diverse  requirements  are  adequately 
reflected  in  the  design  associated  products. 

5.3.3.6.  The  Process  Decision  Program  Chart 

The  Process  Decision  Program  Chart  (PDPC)  is  similar  to  the  Tree 
Diagram  in  that  it  starts  with  a  tree  of  a  process  or  activity  and 
decomposes  the  desired  item  into  constituent  parts.  For  each  level 
of  decomposition,  potential  problems  and  countermeasures  are 
identified.  The  goal  of  such  a  chart  is  to  identify  potential  problems 
early  to  avoid  unpleasant  surprises  later.  Figure  5.3-16  is  a 
pictograph  PDPC  for  the  process  of  creating  a  book.  Boxes  are 
used  to  identify  process  steps,  rounded  boxes  for  potential 
problems  and  unenclosed  text  for  countermeasures.  Rejected 
countermeasures  are  followed  by  an  (X)  and  preferred 
countermeasures  by  an  (O). 


Figure  5.3-16.  Process  Decision  Program  Chart  Example 
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5.3.3.7.  The  Arrow  Diagram 

An  Arrow  Chart  represents  a  time-based  flow  chart  used  to 
evaluate  the  steps  required  to  complete  a  process  based  on  critical 
paths.  The  ancestor  of  the  Arrow  Diagram  is  the  Program 
Evaluation  Research  Technique  (PERT)  Chart.  PERT  Charts  are 
commonly  used  with  CPM  (Critical  Path  Method)  by  project 
managers  to  identify  the  shortest  time  in  which  a  program  can  be 
completed. 

Within  an  Arrow  Chart,  arrows  represent  tasks  that  must  be  done, 
and  nodes  represent  the  start  and  end  points  of  each  task.  Using 
arrows  to  represent  tasks,  each  task  is  labeled  by  the  nodes  it 
connects.  For  example,  the  task  connecting  node  1  and  2  in  the 
following  diagram  is  identified  by  "1,2"  and  is  assigned  a  duration 
of  "1"  (i.e.  1  hour,  day,  week,  year  -  based  on  usage).  Such  charts 
can  illustrate  task  dependencies  and  show  which  tasks  can  be 
executed  in  parallel  to  improve  cycle  time. 


Figure  5.3-17.  Arrow  Chart  -  PERT  Chart  Example 
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THE  PROCESS  MANAGEMENT  NOTEBOOK 


A  Process  Management  Notebook  (PMN)  represents  the  concept  of 
an  integrated  notebook  or  journal  of  information  relating  to  a 
business  enterprise  and  its  associated  processes.  The  PMN  may  be 
housed  in  an  electronic  (automated  form)  consisting  of  electronic 
documents,  automated  models,  and  analytical  tool  results  or  be  a 
simple  manual  notebook. 

Throughout  this  document,  reference  is  made  to  the  PMN  via  the 
icon  shown  in  the  left  hand  margin.  This  section  summarizes  the 
use  of  a  PMN  throughout  the  stages  of  a  reengineering  effort. 

Figure  5.4-1  summarizes  the  contents  of  the  PMN  which  are 
further  outlined  in  the  following  subsections. 


12 1.  Enterprise  Reengineering  Team 

£  V  2.  Business  Goals  and  Targets 

£7  3.  Business  Mission  Statement 

£7  4.  Process  Information 

&  4.  1  Process  Description 

&  4.  2  Process  Reengineering  Assessment 

&  4,  3  Process  Action  Team  Assignment 

&  4.  4  Process  Vision 

&  4.  5  Existing  Process  Design 

&  4.  6  Process  Evaluation  Results 

&  4.  7  New  Process  Design 

&  4.8  Process  Transformation  Plan 


Figure  5.4-1  Process  Management  Notebook  Contents 

Use  and  Control  of  PMN  All  Enterprise  Reengineering  Team  (ERT),  PAT  members,  and 
Contents 

process  workers  should  be  allowed  access  to  selective  portions  of 
the  PMN  to  reduce  duplication  of  effort  and  increase  common 
process  knowledge.  Some  or  all  elements  within  the  PMN  may  be 
considered  company  sensitive  and  should  only  be  made  available 
on  a  need  to  know  basis.  The  ERT  should  decide  upfront,  how  the 
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PMN  will  be  used  and  who  will  have  access  to  pertinent  PMN 
information. 


5.4.1.  ENTERPRISE  REENGINEERING  TEAM  -  PMN  SECTION  1 


Section  1  of  the  PMN  will  include  a  brief  description  of  the 
Enterprise  Reengineering  Team  (ERT).  Generally,  the  ERT 
consists  of  key  managers,  directors  and  thinkers  within  the 
business  enterprise.  The  ERT  sets  the  direction  for  process  change, 
support  the  process  changes  with  necessary  resources,  and  ensure 
that  new  process  designs  meet  business  goals  and  targets.  The  ERT 
description  should  include  identification  of  team  members,  roles 
and  responsibilities  of  each,  team  goals,  and  an  overview  of  the 
environment  in  which  meetings  should  be  held. 

See  Section  2.2  for  further  information  related  to  construction  of  an 
ERT. 


5.4.2.  BUSINESS  GOALS  AND  TARGETS  -  PMN  SECTION  2 


Section  2  of  the  PMN  should  document  the  goals  and  targets 
established  for  the  business.  Such  goals  and  targets  represent  a 
critical  reference  to  both  enterprise  and  process  level  teams.  Each 
business  goal/target  should  be  recorded  along  with  associated 
timeframes  and  baselines  to  be  used  for  future  comparisons.  The 
resulting  goals  and  targets  represent  the  yardstick  by  which  success 
of  a  reengineering  effort  will  be  measured. 

See  Section  2.3.3  for  further  information  related  to  the  construction 
of  a  business  mission  statement. 


5.4.3.  Business  Mission  Statement  -  PMN  Section  3 

A  business  mission  statement  is  recorded  to  guide  all  levels  within 
the  business  enterprise.  Such  a  mission  statement  will  include  the 
business  purpose  along  with  the  goals  established  for  business 
success.  An  example  of  the  general  construction  of  a  mission 
statement  follows,  with  bold  phrases  indicating  areas  for  insertion 
of  specific  business  information: 


Reliability  Analysis  Center  •  P.O.  Box  4700  •  Rome,  NY  13440-4700  •  (315)  337-0900 


CHAPTER  5,  TRANSFORMATION  AND  EVOLUTION 


Page  171 


The  purpose  of  our  business  is  to  B  USINESS 
PURPOSE.  Our  goals  are  to  ESTABLISH  BUSINESS 
DIMENSION  X  and  to  ESTABLISH  BUSINESS 
DIMENSION  Y.  To  meet  these  goals,  we  will 
IMPLEMENT  APPROACH  OVER  TIME. 

Typical  mission  statements  range  from  a  few  sentences  to  a  single 
page.  Management  must  take  care  to  ensure  that  each  sentence 
provides  a  clear  message  to  readers. 

See  Section  2.3.6  for  further  information  related  to  the  construction 
of  a  business  mission  statement. 

5.4.4.  Process  information  -  PMN  Section  4 

For  each  business  enterprise,  more  than  one  business  process  will 
be  identified.  Therefore,  section  4  of  the  PMN  will  be  iterative  in 
nature,  providing  a  subsection  for  each  process  labeled  4.x  along 
with  high  level  description  of  business  process  interaction  as  part 
of  the  section  4  introduction. 


5.4.4. 1.  Process  Description 


For  each  business  process  identified,  a  process  description  is 
recorded.  The  description  should  clearly  describe  the  boundaries 
from  input  to  output  of  the  process.  For  a  simple  example,  fill  in 


the  highlighted  words  to  the  following: 


"this  process  is  initiated  upon  receipt  of  INPUT  from 
SOURCE/SUPPLIER.  Upon  receipt  of  INPUT,  the 

process  must  PERFORM  REQUIRED  PROCESSING  to 

■ 

produce  OUTPUT  for  use  by  DESTINATION  or 

.  ' '  :  ' !  \  *  ^  *******  *  *  *  *  ‘  '  1 


CUSTOMER. 


While  many  process  descriptions  will  be  more  complex  than  the 
example  provided,  too  much  complexity  typically  implies  that  the 
process  has  been  over  described. 

See  Section  3.1.4  for  further  information  related  to  the  construction 
of  business  process  descriptions. 
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5.4.4.2.  Process  Reengineering  Assessment 


As  each  process  is  assessed  to  determine  whether  reengineering  is 
required,  information  is  gathered  and  summarized  relating  to  the 
impact  and  performance  of  the  process  with  respect  to  business 
goals.  Such  information,  including  figures  of  merit  values  and/or 
process  comparisons  must  be  recorded  to  justify  the  basis 
reengineering  decisions. 

See  Section  2.3.6  for  further  information  related  to  the  construction 
of  a  business  mission  statement. 


5.4.4.3.  Process  Action  Team  Assignment 

PAT  responsibilities  should  be  documented  in  a  clear  and  concise 
manner.  Documentation  should  provide  team  members  with: 

•  understanding  of  team  mission 

•  definition  of  individual  roles  with  respect  to  the  team 

•  understanding  of  the  conduct  and  environment  expected 
within  the  team 

•  understanding  of  the  limits  and  latitude  the  team  has  for 
carrying  out  targeted  actions 

See  Section  3.4  for  further  information  related  to  the  construction 
of  a  process  action  teams. 


5.4.4.4.  Process  Vision 

Process  features  defined  as  part  of  creating  a  vision  for  each 
business  process  are  documented  in  a  process  feature  list.  Features 
should  be  listed  in  a  sequential  order  (i.e.  the  order  in  which  they 
would  occur  within  the  process)  and/or  priority  order  (if  features 
are  not  sequence  dependent,  but  may  be  classified  by  importance). 
The  following  is  a  simplified  example  of  a  process  vision  for  a 
customer  response  process. 
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I - 1 - 

The  customer  response  process  for  company  X 
will  exibit  the  following  features: 

•  customers  will  have  immediate  access  to  the 

business  enterprise,  without  delay,  to  report 
problems  of  importance 

•  staff  will  be  able  to  quickly  select  and  record 
problems  reported  by  customers 

•  staff  will  be  able  to  categorize  and 

immediately  route  problems  to  an  available 
service  representative 

•  service  representatives  will  provide  high 

quality  technical  support  to  customers  with 
information  from  all  past  service  calls  at  their 
fingertips 

•  management  will  have  continuous,  automatic 

feedback  on  all  levels  of  customer  responses 
allowing  for  quick  identification  of  high 
volume  problems 

. •  •  ♦  etc. 

. •  •  •  etc. 


Figure  5.4-2  Process  Vision  Example 

See  Section  4.2.1  for  further  information  related  to  the  construction 
of  a  business  process  vision. 


S.4.4.5.  Existing  Process  Design  (As-Is) 


The  design  of  the  "as-is"  process  is  recorded  prior  to  initiating  the 
reengineering  effort.  This  description,  often  recorded  in  the  form  of 
a  model,  describes  the  existing  process  in  as  much  detail  as 
necessary.  In  addition,  information  resulting  from  static  and 
dynamic  models  characterizing  the  performance  of  the  existing 
process  may  also  be  known  and  documented. 

See  Section  4.3  for  further  information  related  to  the  construction 
of  process  models. 


S.4.4.6.  Process  Evaluation  Results 

As  activities  are  evaluated  for  each  process,  the  results  of  the 
evaluation  are  documented  including  such  characteristics  as 
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identification  of  the  activity,  the  type  of  activity  (i.e.  manual, 
automated),  and  the  value  classification  (i.e.  the  reason  the  activity 
adds  or  does  not  add  value).  Recording  evaluation  results  saves 
time  and  effort  during  design  activities  as  well  as  eliminates  the 
need  to  recreate  the  wheel  or  re-analyze  activities  at  a  later  date. 

See  Section  4.4  for  further  information  related  to  process 
evaluation  results.. 


5.4.4.7.  New  Process  Design  (To-Be) 


As  constraints  are  identified  relating  to  the  design  of  a  given 
process,  they  must  be  recorded  for  future  reference.  Without 
documenting  (in  a  reusable  form)  the  constraints  identified, 
designers  will  waste  valuable  time  rethinking  previous  process 
decisions  without  understanding  such  a  discussion  is  likely  of  no 
value.  Those  organizations  using  automated  process  modeling 
tools  may  choose  to  embed  documentation  of  constraints  directly 
into  process  models. 

Once  a  "to-be"  technical  process  design  has  been  evaluated  and 
meets  the  desired  business  goals,  the  new  process  design/model 
must  be  recorded  This  new  design  represents  the  "to-be"  view  of 
the  process  and  acts  as  a  roadmap  for  process  changes.  Additional 
notes  relating  to  why  specific  design  decisions  were  made  should 
also  be  recorded  during  this  stage. 

Social  design,  including  the  staff  responsibilities  supporting  the 
new  organizational  structure  and  process  workflow  should  also  be 
recorded,  once  known. . 

See  Section  4.5  for  further  information  related  to  the  construction 
of  new  process  design  information. 


5.4.4.8.  Process  Transformation  Plan 

After  a  new  process  design  is  evaluated  and  selected,  a  process 
transformation  plan  is  established  and  recorded.  This  plan 
identifies  how  and  when  features  of  the  new  process  design  will  be 
completed. 
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See  Section  5.1.3  for  further  information  related  to  the  construction 
of  a  transformation  plan. 
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A.l.  Terms  &  Definitions 

The  following  represents  a  list  of  terms  used  throughout  this 
document.  The  Keyword  Index  at  the  end  of  this  document  will 
provide  page  references  to  these  and  other  terms  of  interest. 


Activity  Based  Costing  Refers  to  a  means  of  better  understanding  the  costs  associated 

with  processes  and  products.  Activity  Based  Costing  (ABC) 
has  evolved  over  the  years  into  a  mature  approach  to  process 
analysis.  The  concept  of  ABC  is  based  on  the  fact  that  delivery 
of  products  and  services  to  customers  drives  the  execution  of 
business  activities  which  consume  resources  (each  with  a  cost). 

Benchmarking  The  systematic  comparison  of  a  company's  performance  against 

its  competitors  and  against  the  leaders  in  and  out  of  the 
industry. 

Brainstorming  A  common  approach  used  for  generating  ideas  and  organizing 

ideas. 

Business  Process  An  interrelated  series  of  activities  that  convert  business  inputs 

into  business  outputs. 

Business  Process  Health  Refers  to  the  degree  to  which  a  business  process  must  change 

to  reach  the  desired  business  goals  and  targets 

Business  Process  Impact  The  relative  impact  of  the  business  process  on  business  goals 

and  targets 

Business  Process  The  fundamental  rethinking  and  radical  redesign  of  business 

Reengineering  processes  to  achieve  dramatic  improvements  in  critical 

contemporary  measures  of  performance,  such  as  cost,  quality, 
service,  and  speed. 
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Business  Value  Stream 


Controlled  Process 
Evolution 

Data  Reengineering 


Enterprise  Reengineering 
Team 


Evolution 


Forward  Engineering 


Legacy  Business  Process 


Refers  to  the  set  of  all  business  processes  required  to  satisfy  a 
customer  request  or  to  directly  provide  customer  service.  As  a 
general  rule,  the  business  value  stream  starts  with  a  customer 
and  ends  with  the  same  customer. 

Represents  a  process  state  in  which  continuous  process 
improvements  are  utilized  to  evolve  processes  in  a  value  added 
manner  with  respect  to  business  goals. 

Refers  to  the  reorganization  of  information  to  support  either 
manual  or  automated  business  process  improvements.  Such 
reorganization  can  refer  to  construction  of  automated  databases 
or  simply  centralizing  access  to  commonly  used  physical 
documents. 

A  team  generally  consisting  of  key  managers,  directors  and 
thinkers  within  the  business  enterprise.  The  ERT  sets  the 
direction  for  process  change,  support  the  process  changes  with 
necessary  resources,  and  ensure  that  new  process  designs  meet 
business  goals  and  targets. 

Represents  the  gradual  change  of  a  process  over  time.  In 
general,  evolutionary  efforts  are  not  considered  radical  and  do 
not  represent  the  high  risk  and/or  high  potential  breakthrough 
associated  transformation. 

The  design  or  redesign  of  a  new  business  process  to  include 
remnants  of  the  existing  process  design  (the  "as-is"  design 
which  may  be  derived  via  reverse  engineering)  and  new 
business  process  requirements.  Commonly  applies  when 
process  boundaries  are  modified. 

Refers  to  processes  (consisting  of  people,  systems,  and 
organizational  structure)  that  have  been  institutionalized  within 
a  business.  The  use  of  the  term  "Legacy  Systems"  has  been 
widely  used  by  both  government  and  commercial  business 
sectors  to  refer  to  institutionalized  hardware/software  systems. 
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NonValue  Added  Activity 


Process  Management  Life 
Cycle 

Process  Management 
Notebook 


Restructuring 


Retargeting 


Reverse  Engineering 


Transformation 


Activities  which  exist  due  to  the  physical  implementation,  but 
generally  do  not  improve  the  overall  quality  of  the  process  or 
product. 

The  set  of  phases  throughout  the  life  of  a  business  process 
including  engineering  (conception),  evolution  (adaptation),  and 
reengineering  (re-evolution),  and  retirement. 

Refers  to  the  concept  of  an  integrated  notebook  or  journal  of 
information  relating  to  a  business  enterprise  and  its  associated 
processes.  The  Process  Management  Notebook  (PMN)  may  be 
housed  in  an  electronic  (automated  form).  The  PMN  may 
consist  of  electronic  documents,  automated  models,  and 
analytical  tool  results  or  be  a  simple  manual  notebook. 

Refers  to  the  reorganization  of  people,  systems,  and 
infrastructure  to  perform  the  same  basic  functions  in  a  more 
efficient  manner. 

Predominantly  used  as  part  of  software  reengineering  to 
describe  the  transport  of  existing  source  code  (software)  to  a 
new  host  system.  Organizations  are  considering  the  use  of 
retargeting  at  a  business  process  level;  the  results  would 
include  transporting  business  processes  to  entirely  new 
locations,  buildings,  and  environments. 

Refers  to  the  extraction  of  the  existing  design  from  the  current 
implementation.  As  a  rule  of  thumb,  reverse  engineering  will 
result  in  an  "as-is"  view  of  the  system. 

Represents  the  implementation  of  fundamental  and  radical 
changes  to  a  business  process,  potentially  resulting  in  a  total 
process  redesign.  With  this  in  mind,  transformation  represents  a 
form  of  rapid  evolution,  speeding  evolution  to  reach  business 
targets  in  a  faster  fashion. 
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Value  Added  Activity 


Represent  steps  within  process  execution  which  are  required  to 
convert  process  inputs  into  process  outputs. 
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A.2.  Organizations  &  Information  Sources 

The  following  organizations  and  information  sources  were 
identified  during  research  activities  conducted  to  complete  this 
document. 


Society,  o  f  En  terprise  Engineering 
1900  Founders  Drive 
Kettering,  Ohio  45402 
Phone:  513-259-4702 
Fax:  513-259-4343 

BPR  Information  Clearinghouse 
Defense  Information  System  Agency  (DISA) 

Hotline:  1-800-TELL-CIM 

Enterprise  Engineering  (The  National  Publication  far  BPR ) 

7777  Leesburg  Pike  Suite  315N 

Falls  Church,  Virginia  22043 

Phone:  703-761-0646  (In  D.C.  Metro  Area) 

Phone:  800-670-4BPR  (Outside  D.C.  Metro  Area) 

Fax:  703-761-0766 

Air  Force  Software  Technology  Support  Center  (STSC} 

OO-ALC/TISEC 

7278  Fourth  Street 

Hill  AFB,  UT  84056-5205 

Phone:  801-777-7703 

Workflow  and  Reengineering  International  Association  (WARIA ) 

3640  North  Federal  Highway 

Lighthouse  Point,  FL  33064 

Phone:  305-782-3376 

Internet:  waria@gate.net 

Business  Process  Reengineering  Listserver 

BPR-L@IS.TWI.TUDELFT.NL 
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Short  Circuit  (The  Newsletter  o  f  Engineering  Empowerment! 

FES.  Ltd. 

PO  Box  158 
Stuart,  FL  34995 
Phone:  407-229-5654 

Ohio  State.  Higher  Education  Business  Process  Reengineering  Listserver 
BPRREENG-L@lists.acs.ohio-state.edu 

The  Business  Process  Reengineering  Study.  Group  (BPRSG) 

Hanson  Associates,  Claverton  House,  Longwood  Court 
Cirencester,  Gloucestershire  GL7  1YG  England 
Phone:  444-(0)  941-120118 
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A. 3.  BOOKS  &  ARTICLES 

The  following  list  of  books  and  articles  provide  excellent  reference 
materials  for  those  wishing  to  increase  their  knowledge  on  topics 
related  to  reengineering  and  quality  improvement.  This  list  is  not 
restricted  to  those  articles  directly  referenced  as  part  of  this 
publication. 


1.  "10  Rules  of  Thumb  for  Reengineering",  HR  Focus,  Jan.  1994,  vol.  71,  p.  18. 

2.  Aaron,  Robert  D.,  "Total  Quality  Management:  What  Processes  Do  You  Own?  How 
Are  They  Doing?",  Program  Manager,  September/October  1989. 

3.  Akao,  Yogi,  Quality  Function  Deployment  Integrating  Customer  Requirements  into 
Product  Design,  Productivity  Press. 

4.  Alter,  Allan  E.,  "No  More  'Business  As  Usual' ",  Computerworld,  Dec.  27, 1993/Jan.  3, 
1994,  vol.  28,  p.  24. 

5.  American  Productivity  and  Quality  Center,  Planning,  Organizing,  and  Managing 
Benchmarking  Activities:  A  User's  Guide,  APQC,  1992. 

6.  American  Society  for  Quality  Control,  The,  NASA  Excellence  Award  For  Quality  And 
Productivity  -Application  Guidelines  -  1989  -  90,  Milwaukee,  WI. 

7.  Ananda,  A.  L.,  and  B.  Srinivasan,  eds..  Distributed  Computing  Systems:  Concepts  and 
Structures,  IEEE  Computer  Society  Press,  1991. 

8.  Andrews,  Dorine  C.,  and  Susan  K.  Stalick,  Business  Reengineering:  The  Survival 
Guide,  Englewood  Cliffs:  Prentice-Hall,  1994. 

9.  Andrews,  Dorine,  "Are  automated  tools  really  necessary  for  BPR?",  Enterprise 
Engineering,  March  1995,  p.  24. 

10.  Arnold,  Robert  S.,  Software  Reengineering,  Los  Alamitos,  CA,  Institute  of  Electrical 
and  Electronics  Engineers  (IEEE)  Computer  Society  Press,  1994. 

11.  Arthur,  Losell  Jay,  Rapid,  Evolutionary  Development,  John  Wiley  &  Sons,  Inc.,  1992. 

12.  AT&T  Quality  Steering  Committee,  Reengineering  Handbook,  AT&T  Bell 
Laboratories,  1991. 
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13.  Aubrey,  Charles  A.,  and  Patricia  K.  Felkins,  "Teamwork:  Involving  People  in  Quality 
and  Productivity  Improvements",  Quality  Resources 

14.  Bales,  Robert  F.,  Interaction  Process  Analysis,  Addison-Wesley  Press 

15.  Balm,  Gerald  J.,  Benchmarking:  A  Practitioner's  Guide  for  Becoming  and  Staying  Best 
of  Best,  Schaumburg,  HI.,  Quality  &  Productivity  Management  Association,  1992. 

16.  Band,  William  A.,  Touchstones:  Ten  New  Ideas  Revolutionizing  Business,  Wiley  & 
Sons. 

17.  Batten,  Joe  D.,  Tough-Minded  Leadership,  New  York,  AMACOM,  1989. 

18.  Bechtell,  Michele  L.,  The  Management  Compass:  Steering  the  Corporation  Using 
Hoshin  Planning,  American  Management  Association,  1995. 

19.  Belgard,  Fisher,  Rayner,  Inc.,  Phases  of  Team  Involvement,  1989 

20.  "Benchmarking:  A  Special  Report",  Financial  World,  September  17,  1991. 

21.  Berger,  Gene,  How  Do  You  Measure  the  Quality  of  Services?,  Mitre,  1992 

22.  Biesada,  Alexandra,  "Tired  of  Getting  Blindsided?  Study  How  the  Competition  Plans 
for  Tomorrow",  Financial  World,  September  29,  1992,  p.  30. 

23.  Blackburn,  Joseph,  "The  Time  Factor",  National  Productivity  Review,  Autumn,  1990, 
vol.  9,  no.  4. 

24.  Boeing  Aerospace  Co.,  Total  Quality  Improvement  -  A  Resource  Guide  To 
Management  Involvement,  Seattle,  WA,  1985. 

25.  Booch,  Grady,  Object-Oriented  Design  with  Applications,  Benjamin-Cummings 
Publishing  Co.,  1991. 

26.  Box,  George  and  Norman  R.  Draper,  Empirical  Mo  del- Building  and  Response 
Surfaces,  John  Wiley  &  Sons,  Inc.,  1987. 

27.  Box,  George  and  Soren  Bisgaard,  "The  Scientific  Context  of  Quality  Improvement", 
Quality  Progress,  June  1987. 

28.  Brassard,  Michael,  ed.,  The  Memory  Jogger,  GOAL/QPC,  Methuen,  MA,  1988. 

29.  Brassard,  Michael,  The  Memory  Jogger  Plus+,  GOAL/QPC,  1989. 

30.  Braverman,  Jerome  D.,  Fundamentals  of  Statistical  Quality  Control,  Reston. 

31.  Bremer,  Michael  S.,  "Linking  Strategic  Management  And  Ongoing  Quality 
Improvement",  National  Productivity  Review,  Winter  1988/89,  vol.  8,  no.  1. 
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32.  Brooks,  Frederick  P.,  The  Mythical  Man-Month,  Addison- Wesley,  1975. 

33.  Brown,  Paul  B.,  "Drawing  a  Road  Map  (Strategic  Benchmarking:  Business  Process 
Redesign)",  Financial  World,  September  29,  1992,  vol.  161,  p.  38. 

34.  Budde,  Reinhard  et  al.,  Prototyping,  Springer-Verlag,  1991. 

35.  Burk,  Karen  B.,  and  Douglas  W.  Webster,  Ph.D.,  Activity  Based  Costing  and 
Performance,  American  Management  Systems. 

36.  Burr,  John  T.,  "The  Tools  Of  Quality  -  Part  I:  Going  With  the  Flow(chart)",  Quality 
Progress,  June  1990. 

37.  Butz,  Howard  E.,  "Strategic  Planning:  The  Missing  Link  in  TQM",  Quality  Progress, 
May  1995,  pl05. 

38.  Byrne,  John  A.,  "Paradigms  For  Postmodern  Managers",  Business  Week:  A  Special 
Report  on  Reinventing  America ,  1992,  p.  62. 

39.  Camp,  Robert  C.,  Benchmarking:  The  Search  for  Industry  Best  Practices  that  Lead  to 
Superior  Performance,  Milwaukee,  MN,  ASQC  Quality  Press,  1989. 

40.  Coppola,  Anthony,  "Measuring  the  Quality  of  Knowledge  Work",  Quality  and 
Reliability  International,  1991,  vol.  7,  pp.  411-416. 

41.  Coppola,  Anthony,  TQM  Toolkit,  Reliability  Analysis  Center,  1993 

42.  Champy,  J.A.,  and  M.  Hammer, "Help  Wanted:  Heroes  and  Visionaries  Preferred", 
Computerworld,  March  1989. 

43.  Classe,  Alison,  "Don't  Tinker  With  It:  BPR  It!",  Accountancy,  July  1993,  vol.  1 12,  pp. 
64-66. 

44.  Conti,  Tito,  "Process  Management  and  Quality  Function  Deployment",  Quality 
Progress,  December,  1989. 

45.  Covey,  S.,  The  Seven  Habits  of  Highly  Effective  People,  Simon  and  Schuster,  1989. 

46.  Covey,  Stephen  R.,  Principle-Centered  Leadership,  Summit  Books,  1990. 

47.  Cringley,  Robert  X.,  "Made  in  Japan",  Upside,  July  1992,  p.  47. 

48.  Crosby,  Philip,  Quality  is  Free,  McGraw-Hill,  1979. 

49.  Cumberland  Group,  The,  Critical  Processes  -  Process  Management,  1987  (Revised 
3/88). 
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50.  Curid,  Cheryl,  The  Reengineering  Toolkit:  Fifteen  Tools  and  Technologies  for 
Reengineering  Your  Organization,  Rocklin,  CA,  Prima  Publishing,  1994. 

51.  Davenport,  T.H.,  M.  Hammer,  and  T.J.  Metsisto,  "How  Executives  Can  Shape  Their 
Company's  Information  Systems",  Harvard  Business  Review,  Mar/ Apr  1989. 

52.  Davenport,  Thomas  H.,  "Need  Radical  Innovation  and  Continuous  Improvement? 
Integrated  Process  Reengineering  and  TQM",  Planning  Review,  May/June  1993,  vol. 

21,  pp.  6-12. 

53.  Davenport,  Thomas  H.,  Process  Innovation:  Reengineering  Work  Through  Information 
Technology,  Boston,  MA,  Harvard  Business  School  Press,  1993. 

54.  Davenport,  Thomas,  and  James  Short,  "The  New  Industrial  Engineering:  Information 
Technology  and  Business  Process  Redesign",  Sloan  Management  Review,  Summer 
1990. 

55.  Deming,  W.  Edwards,  Japanese  Methods  for  Productivity  and  Quality,  George 
Washington  University,  Washington,  DC,  1981. 

56.  Deming,  W.  Edwards,  Out  of  the  Crisis,  Cambridge,  MA,  MIT  Press,  1986. 

57.  Deming,  W.  Edwards,  Quality,  Productivity,  and  Competitive  Position,  Massachusetts 
Institute  of  Technology,  Center  for  Advanced  Engineering  Study,  Cambridge,  MA, 
1982. 

58.  Department  of  Defense,  Functional  Process  Improvement,  Defense  Information 
Systems  Agency  (DISA),  Washington,  DC,  1992. 

59.  Department  of  Defense,  Total  Quality  Management  -  A  Guide  For  Implementation, 
Procurement  Associates,  Inc.,  Covina,  CA,  February  15,  1989. 

60.  Digital,  "The  New  Realities  in  Manufacturing:  Winning  Success  in  the  Global 
Marketplace"  ,  Managing  Automation,  April  1992. 

61.  Dobyns,  Lloyd,  "Ed  Deming  Wants  Big  Changes,  And  He  Wants  Them  Fast",  Quality 
Digest,  September,  1990. 

62.  Dow  Chemical  Co.,  The,  Quality  Performance  Guidebook. 

63.  Drucker,  Peter  F.,  Post-Capitalist  Society,  Harper  Business,  1993. 

64.  Endoso,  Joyce,  "BPR  Wave  Has  Integrators  Recasting  Themselves  as  Consultants", 
Washington  Technology,  February  23,  1995,  Vol.  9,  No  22. 
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Group. 
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"How  Quality  Is  Taught  Can  Be  As  Important  As  What  Is  Taught",  Quality  Progress, 
January,  1990. 

68.  Figlio,  R.,  "Benefits  of  Reengineering",  Software  Maintenance  Assoc.  Conference 
Proceedings,  Software  Maintenance  Assoc.,  New  York,  1989. 

69.  Fleming,  Candace,  and  Barbara  von  Halle,  Handbook  of  Relational  Database  Design, 
Addison-Wesley,  1989. 

70.  Fombrun,  Charles  J.,  Turning  Points:  Creating  Strategic  Change  in  Corporations,  New 
York,  McGraw-Hill,  1992. 
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A.4.  Automated  Tools 

Depending  on  the  depth  and  breadth  of  the  reengineering  effort,  as 
well  as  existing  business  process  maturity,  automated  tools  may  be 
helpful  in  supporting  BPR.  The  authors  caution  that  tools  are  not  a 
replacement  for  common  sense  thinking  and  a  sound  business 
process  focus.  In  general,  automated  tools  represent  a  mechanism 
by  which  BPR  practitioners  may  better  organize,  plan,  evaluate, 
and  monitor  process  changes. 

A  brief  overview  of  the  BPR  tool  dilema  is  presented  in  an  article 
from  the  Q&A  section  of  the  March  1995  issue  of  Enterprise 
Reengineering  magazine  entitled  " Are  Automated  Tools  Really 
Necessary  for  BPR?".  This  article  has  been  reprinted  for  your 
convenience,  with  the  permission  of  Enterprise  Reengineering  in 
the  following  subsection  (A.4.1).  In  addition,  an  abbreviated  list  of 
tools  identified  by  the  authors  during  research  supporting  this 
document  has  been  included  in  subsection  A.4.2.  This  abbreviated 
tool  list  is  not  meant  to  be  inclusive  in  nature,  is  not  an 
endorsement  of  any  specific  tool,  and  only  represents  a  small 
sample  of  the  tools  within  the  marketplace. 

A.4.1  Are  Automated  Tools  Really  Necessary  for  BPR? 

This  subsection  (A.4.1)  is  a  reprint  of  an  article  on 
Pages  24-25  in  the  March  1995  issue  of  Enterprise 
Reengineering  and  has  been  reprinted  with  the 
permission  of  authorized  Enterprise  Reengineering 
magazine  representatives.  Phoney  (703)  761-0646 


A.4.1.1  Issue: 

The  promise  of  BPR  automation  is  seductive.  It  promises  that 
project  success  can  be  attained  by  the  use  of  software  tools  and  that 
these  tools  can  solve  all  your  project  problems.  And,  quite  frankly, 
many  of  us  are  quite  easily  seduced.  Tools  are  concrete  and 
visible.  You  know  when  you  have  produced  something  with  them. 
Unlike  the  ambiguity  of  culture  change,  you  have  results  to  show 
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your  management.  But  as  you  know,  BPR  is  much  more  than 
diagramming  process  redesigns.  It  is  changing  the  way 
organizations  operate  and  how  people  behave.  So,  are  these  tools 
really  necessary? 


A.4.1.2  Answer: 

BPR  project  quality  is  enhanced  through  the  use  of  tools,  but  you 
have  more  tool  options  available  than  you  think.  First,  let's 
broaden  the  definition  of  tools  to  include  both  manual  and 
automated  mechanisms  because  they  both  play  a  role  in  your  BPR 
project. 

Let's  examine  the  role  of  tools  from  two  perspectives: 

•  Functions  they  can  support  within  the  BPR  methodology. 

•  Simplicity  or  complexity  of  the  tool  when  you  attempt  to  use 
it.  We  have  not  found  a  single  tool  supplying  all  the 
functionality  a  team  might  need  to  support  its  BPR  project. 

Tool  functions  include: 

•  Unstructured  data  capture 

•  Structured  data  capture 

•  Structured  data  analysis 

•  Simulation 

•  Project  management 

•  Document  production 
Each  function  is  defined  below: 

•  UNSTRUCTURED  DATA  CAPTURE  is  the  ability  to 

keep  notes  and  ideas  as  text  or  graphics  for  easy  reference. 
Throughout  the  life  of  a  BPR  project,  there  are  many 
instances  where  discussions  generate  many  instances  where 
discussions  generate  many  potentially  useful  facts,  ideas, 
and  options  which  do  not  "fit"  into  a  particular  structure  at 
the  time  of  their  generation. 
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•  STRUCTURED  DATA  CAPTURE  is  the  ability  to  store 
and  maintain  objects  in  diagrams  which  structure  the 
definition  of  objects  and  their  relationships  to  each  other. 
Many  of  these  diagrams  were  first  used  in  TQM  (total 
quality  management)  and  in  information  systems  design 
methodologies.  Some  diagrams  include  fishbone,  Paerto, 
scatter,  matrix,  decomposition,  dependency,  event,  entity 
relationship,  entity  tables,  data  flow,  state  transition,  and 
decision-condition.  These  diagrams  can  link  to  each  other  or 
be  used  in  a  stand  alone  form. 

•  STRUCTURED  DATA  ANALYSIS  is  the  ability  to 
examine  the  data  captured  in  structured  diagrams  to  uncover 
errors  and  inconsistencies  in  the  structures. 

•  SIMULATION  is  the  ability  to  test  a  real  world 
environment  by  running  transactions  or  business  case 
situations  against  a  process  design  (a  linked  set  of  structured 
data  capture  diagrams)  to  determine  if  the  process  design 
functions  as  expected.  The  outcome  of  simulation  is 
measurement  results  providing  operational  performance 
timing,  resource  consumption  costs,  and  identification  of 
transaction  bottlenecks  and  waiting  times.  This  information 
is  used  for  calculation  of  benefits  and  expected  return  on 
investment  for  reengineering. 

•  PROJECT  MANAGEMENT  is  the  ability  to  (1)  define, 
schedule  and  assign  project  activities,  (2)  record  project 
issues,  (3)  monitor  progress  and  report  changes  in  activity 
accomplishment  and  issue  resolution,  and  (4)  maintain  and 
control  changes  to  designs,  plans  and  issue  lists. 

•  DOCUMENTATION  PRODUCTION  is  the  ability  to 
format  and  generate  project  deliverables.  This  may  include 
adding,  changing  or  deleting  data  captured,  analyzed,  tested 
and  monitored  during  the  project.  For  automated  tools,  this 
includes  the  ability  to  import  data  into  the  tool  or  export  data 
to  other  tools  for  formatting  and  deliverable  generation. 
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These  tools  functions  are  used  at  different  phases  of  a  BPR  project 
life  cycle.  Figure  1  maps  tool  function  use  to  BPR  life  cycle  phase. 
As  we  stated  earlier,  not  all  BPR  tools  perform  all  functions.  Tool 
complexity  is  organized  into  four  categories:  simple  manual  tools, 
simple  automated  tools,  and  complex  automated  tools,  and 
complex  integrated  and  automated  tools.  Each  is  defined  with 
examples  in  Figure  2.  As  tool  complexity  increases,  so  does  tool 
expertise  required  to  operate  the  tool  and  as  a  result,  the  amount  of 
time  required  to  learn  the  tool.  The  most  complex  tools  have  a 
BPR  methodology  embedded  within  them.  This  can  lead  to  a  tool- 
driven  versus  user-driven  approach  to  reengineering.  Others 
provide  an  array  of  features  that  are  used  in  any  sequence  based 
upon  user-defined  needs.  For  example,  to  build  information 
models,  a  tool  may  or  may  not  allow  the  user  to  build  entity  tables 
before  building  an  entity  relationship  diagram. 
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(1)  VVG  is  the  Vision,  Values,  &  Goals  Statement, (2)  Includes  Design  Testing, (3)  Includes  Obtaining  Implementation  Approval 


Figure  1:  BPR  Methodology  and  Tool  Functionality 
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Potential  Tool 
Functionality' 

#1:  Simple 

(Manual) 

#2:  Simple 
(Automated) 

#3:  Complex 
(Stand  alone/ 
Automated) 

H9 

Physical  Materials: 

•  Flip  chart 

•  Post-Its® 

•  Worksheets* 

•  Transparencies 

Software  Packages: 

•  Word  Processing 

•  Presentation  Pkg. 

•  Spreadsheets 

•  Groupware 

Software  Packages: 

•  Process  and  data 
modeling 

•  Workflow 

•  Project  mgt. 

Software  Packages: 

•  CASE/code 
generators 

Unstructured  Data 
Capture 

✓ 

~7 

mmc::  "'Mi 

Structured  Data 
!  Capture 

— M  ill 
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KlfeSS  8 

Structured  Data 
Analysis 

7 

1  111  §  • 

Simulation 

y 

Project  Management 

✓ 

Documentation 

Production 

✓ 

...... . . : 

*Worksheets  are  structured  data  collection  mechanisms  (forms). 


Figure  2:  Tool  Complexity  Continuum 


What  tools  should  you  use  on  your  BPR  project?  There  is  no  "one 
size  fits  all"  answer.  Every  project  has  its  own  particular  tool 
requirements.  As  you  plan  your  BPR  project,  here  are  the  factors 
which  help  to  decide  what  tools  to  use: 

•  Cost:  The  most  complex  tools  in  category  4  on  the  chart  in 
Figure  2  are  expensive.  You  can  count  on  spending  $5,000 
or  more  per  copy  and  may  require  the  additional  purchase  of 
special  hardware.  Prices  in  category  3  range  from  $2,000  to 
$10,000.  Category  2  software  ranges  from  $100  to  $2,000 
per  copy.  Using  software  already  in  place  is  a  smart  way  to 
save  money. 

•  Project  Size:  The  larger  the  number  of  processes  within 
your  project's  scope,  or  the  number  of  organizations  affected 
by  the  project,  the  greater  the  need  for  automated  tool 
support  affected  by  the  project,  the  great  the  need  for 
automated  tool  support.  Project  management  software  is 
recommended  for  all  but  the  smallest  projects.  Large 
projects  also  require  automated  support  for  capturing, 
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analyzing,  and  maintaining  designs  through  multiple  design 
and  review  sessions. 

•  Justification :  Both  large  and  small  projects  can  and  should 
have  a  dramatic  impact  on  business  operations.  When 
looking  at  the  current  situation  to  determine  whether  or  not 
to  reengineer,  current  performance  and  financial 
measurement  results  can  be  captured  and  analyzed.  Spread¬ 
sheets,  workflow  tools  and  even  simulators  are  used  to  do 
this.  Category  4  simulators  are  very  helpful  in  providing 
estimated  results  from  tests  of  the  designs.  These  results  are 
instrumental  in  identifying  savings  and  productivity 
improvements  needed  to  justify  the  cost  of  implementation. 
The  alternative  to  automated  simulation  is  a  manual  process 
of  structured  design  walk  throughs  (which  can  take  just  a 
few  days)  or  pilot  testing  in  a  live,  but  controlled, 
environment  (which  can  take  several  months).  For  more 
details  on  these  options,  we  suggest  reading  chapter  5  of  the 
book  Business  Reengineering:  The  Survival  Guide. 

•  Reusability:  The  reuse  of  process  designs  for  other 
processes  can  be  supported  through  those  category  3  and  4 
tools  which  provide  repositories.  With  a  central  repository 
and  multiple  workstations  linked  to  the  repository,  project 
teams  can  share  designs  efficiently. 

•  Linkage  to  systems  development:  If  your  information 
technology  organization  builds  application  and  data  base 
solutions  using  certain  types  of  code  generation  or 
application  development  tools,  then  it  certainly  makes  sense 
to  use  the  category  3  and  4  tools  which  link  or  contain  code 
generators. 

•  Design  and  Planning  Techniques:  Team-based  design 
using  facilitated  workshops  and  meetings  require  simple 
manual  category  1  tools.  You  just  can't  do  it  without  them. 
Tools  from  other  categories  are  used  in  sessions  to  speed 
documentation  process  and  provide  rapid  feedback  to 
participants  on  their  design  decisions. 
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•  Learning  Curve:  The  more  sophisticated  the  tool,  the  more 
time  it  can  take  to  acquire  the  skills  needed  to  use  it 
effectively  on  your  BPR  project.  Learning  involves 
understanding  the  principles  and  rules  of  conceptual 
framework  drive  tool  operation  and  the  skills  of  tool  feature 
manipulation.  Both  classroom  training  and  tutorials  may  be 
needed  to  acquire  skill  and  knowledge.  If  project  time  lines 
are  short  and  team  resources  are  limited,  it  may  not  be  wise 
to  use  a  tool  which  require  weeks  or  months  to  learn. 

What  do  we  use  in  our  BPR  projects?  All  of  our  projects  require 
category  1  and  2  tools.  We  use  category  3  tools  when  we,  rather 
than  our  clients,  are  responsible  for  documenting  designs  and 
supporting  information.  Maintainable  process  and  data  models  are 
critical  to  these  kinds  of  projects,  and  we  find  their  relatively  low 
cost  and  strong  analytical  functionality  a  plus.  Where  project  costs 
approach  seven  figures,  a  category  4  simulator  has  been  essential 
in  explaining  the  implications  of  the  design  across  the 
organization.  Simulators  do  require  accurate  base  line  data. 
Without  it,  benefit  calculations  will  be  skewed. 

In  conclusion,  tools  can  enhance  your  BPR  project,  but  they  should 
not  become  the  project  focus.  Project  focus  should  be  on  the 
people  you  bring  together  for  business  reengineering.  Stimulating 
their  creativity,  helping  them  let  go  of  the  past,  and  energizing  their 
commitment  to  change  are  your  top  priorities. 
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The  following  represents  an  abbreviated  list  of  tools  identified  by 
the  authors  during  research  supporting  this  document.  This 
abbreviated  tool  list  is  not  meant  to  be  inclusive  in  nature,  is  not  an 
endorsement  of  any  specific  tool,  and  only  represents  a  small 
sample  of  the  tools  within  the  marketplace. 


BPwin,  Logicworks,  Inc.,  609-252-1177,  Business  process  modeling  and  analysis. 
Integrated  with  ERWIN  CASE  development  tools. 


COSMO,  Coe-Truman  Technologies,  Inc.,  703-836-2671,  Process  modeling  and  data 
definition. 


Design/IDEF  and  WorkFlow  Analyzer,  Meta  Software  Corporation,  617-576-6920, 
Process  modeling  and  workflow  analysis. 


Extend+BPR,  Imagine  That,  Inc.,  408-365-0305,  Process  modeling  and  dynamic 
simulation  with  specific  BPR  module  libraries. 


INTEC  Tools,  INTEC  Systems,  Inc.,  Business  process  improvement  methodology. 


Knowledge  Worker  System,  DoD's  BPR  Implementation  Center,  For  reengineering 
processes  at  the  workstation. 


MAXIM,  KnowledgeWare,  Inc.,  1-800-675-2100,  Reengineering  and  process  analysis 
toolset  integrated  with  CASE  development  platform. 
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META  VISION,  Galen  Group,  Inc.,  A  process  analysis,  design,  and  development  tool. 


Model  Solutions,  Richard  S.  Carson  &  Associates,  A  BPR,  workflow,  and  system  design 
methodology. 


OPENAVorkflow,  Wang,  A  workflow  system  development  tool. 

ProCap,  Knowledge  Based  Systems,  Inc.,  800-808-KBSI,  Process  documentation  and 
analysis. 


Process  Charter,  Scitor  Corporation,  800-549-9876,  Business  process  modeling  and 
analysis 

ProMap,  Invictus  Systems  Corporation,  703-503-8060 

ReThink,  Gensym  Corporation,  703-266-0203,  Automated  process  drawing  and  mapping 
tool.,  Business  process  modeling  and  analysis  tool. 

ServiceModel,  ProModel  Corporation,  801-223-4600,  Static  and  dynamic  business 
process  modeling. 

System  Architectect,  Popkin  Software  and  Systems,  Inc.,  800-732-5227,  Process 
analysis  and  design  toolset  for  client/server  environment. 

TeamFlow,  CFM  Inc.,  617-275-5258,  Process  and  organization  flowcharting. 


TemPRO,  Software  Consultants  International  Limited,  206-631-4212,  Business  process 
analysis  and  reengineering  toolset. 

The  Workflow  Factory,  Delphi  Consulting  Group,  Inc.,  1-800-991-1511,  Activity 
modeling  and  workflow  analysis.  Windows  graphical  interfaces  with  industry  specific 
icon  sets. 


VISO,  WYSIWYG  flowcharter  capable  of  export  to  static  modeling  packages. 

WizdomWorks,  Wizdom  Systems,  Inc.,  703-548-7900,  Integrated  process  reengineering 
and  database  design. 
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Mechanical  Applications  in  Reliability  Enaineerina  *Price  Reduced* 

5 

wmm 

$85 

QREF 

RAC  Quick  Reference  Guides 

5 

mm 

HSE9 

SOAR-6 

ESD  Control  in  the  Manufacturinq  Environment 

5 

$50 

SOAR-4 

Confidence  Bounds  for  System  Reliability 

5 

$50 

K339 

WHDK 

New  Weibull  Handbook 

6 

B*£JH 

$94 

Reliable  Application  of  Components 


PSAC 

Parts  Selection,  Application  and  Control 

6 

$75 

■E£E9 

EOES 

EOS/ESD  Guidelines 

6 

$50 

CAP 

Reliable  Application  of  Capacitors 

6 

$50 

PEM2 

Reliable  Application  of  Plastic  Encapsulated  Microcircuits 

6 

$75 

■E309 

MCM  1 

Reliable  Application  of  Multichip  Modules 

6 

$50 

■ESS 

Component  Publications 


MFAT-1 

Microelectronics  Failure  Analysis  Techniques:  A  Procedural  Guide 

7 

$70 

$80 

MFAT-2 

GaAs  Microcircuit  Characterization  and  Failure  Analysis  Techniques: 

A  Procedural  Guide 

7 

$50 

$60 

MFAT1  &2 

Combined  set  of  MFAT-1  and  MFAT-2 

7 

$100 

$120 

QML 

Qualified  Manufacturer's  List:  New  Device  Manufacturing  and 
Procurement  Technique 

7 

$50 

$60 

GAAS 

An  Assessment  of  Gallium  Arsenide  Device  Quality  and  Reliability 

7 

$50 

$60 

ATH 

Analoq  Testinq  Handbook 

7 

$100 

$120 

PRIM 

A  Primer  for  DoD  Reliability,  Maintainability,  Safety  and  Logistics 
Standards  *Price  Reduced* 

7 

$50 

$60 

Quality  Improvement 


SPAT 

Software  Enqineerinq  Process  Group  Handbook 

8 

$30 

m 

BPRQ 

Business  Process  Reenqineerinq  for  Quality  Improvement 

8 

$75 

TQM 

TQM  Toolkit 

8 

■329 

■U9 

SOAR-7 

A  Guide  for  Implementinq  Total  Quality  Manaqement 

8 

■ESS 

SOAR-8 

Process  Action  Team  Handbook  *Price  Reduced* 

8 

■m 

■E&9 

Computer  Products 


CART 

RAC  Computer-Aided  Reliability  Traininq  Course 

9 

$300 

$340 

217N2 

MIL-HDBK-217F,  Notice  2  (Macintosh  Format)  *Price  Reduced* 

9 

$50 

■ESS 

338D 

MIL-HDBK-338B  (Draft)  (Macintosh  Format)  *Price  Reduced* 

9 

$50 

$60 

NPRD-P 

NPRD-95  PC  Version  (with  Informix  run-time  module  and  hard  copy  of 
book  also  included) 

9 

$475 

NPRD-P 

NPRD-95  PC  Version  (without  run-time  module  for  those  owning 
NPRD-95  software  -  hard  copy  of  book  also  included) 

9 

$275 

$315 

NRPS 

Nonoperatinq  Reliability  Prediction  System  *Price  Reduced* 

9 

$350 

$390 

VPRED 

VHSIC  Reliability  Prediction  Software 

9 

$100 

$120 

Concurrent  Engineering  Series 


ITCE 

Introduction  to  Concurrent  Enqineerinq 

10 

$75 

WCCA 

Worst  Case  Circuit  Analysis  Application  Guidelines 

10 

$75 

$85 

FMECA 

Failure  Mode,  Effects  and  Criticality  Analysis 

10 

$75 

(■££9 

FTA 

Fault  Tree  Analysis  Application  Guide 

10 

$75 

$85 

Shipping  and  Handling  (Note:  Different  postal  rates  for  NPRD  and  VZAP)  -  See  Back 

Quantity  Discount -See  Back 

□  ZRG  RAC  Journal  (Free)  Order  Total 

RCode:  BPRQ 


Ordering  Information  -  _  - .  . — 

Ordering 

Fax  to  (315)  337-9932  or  mail  to  Reliability  Analysis  Center,  P.O.  Box  4700,  Rome,  NY,  13442-4700. 

Prepayment  is  preferred.  Credit  cards  (VISA,  AMEX,  MasterCard)  are  accepted  for  purchases  of  $25  and  up.  All  Non-US 
orders  must  be  accompanied  by  a  check  drawn  on  a  US  bank.  Make  checks  payable  to  IITRI/RAC. 

Shipping  &  Handling 

US  orders  add  $4.00  per  book,  $6.00  for  First  Class.  Non-US  add  $10.00  per  book  (allow  8-10  weeks  delivery)  for 
surface  mail,  $1 5.00  per  book  for  air  mail  ($25.00  for  NPRD  or  VZAP). 

Quantity  Discounts 

Discounts  are  available  for  10+  copies.  For  discount  prices  call  (800)  526-4802  or  (315)  339-7047. 

Military  Agencies 

Blanket  Purchase  Agreement,  DD  Form  1155,  may  be  used  for  ordering  RAC  products  and  services.  Indicate  the 
maximum  amount  authorized  and  cutoff  date  and  specify  products  and  services  to  be  provided.  Identify  vendor  as 
IIT  Research  Institute/Reliability  Analysis  Center. 

To  place  an  order 

Write  to:  Reliability  Analysis  Center,  P.O.  Box  4700,  Rome,  NY  13442-4700 
Call:  (800)  526-4802,  (315)  339-7047 

Fax:  (315)  337-9932 

E-mail:  rac@mail.iitri.com 


Please  return  with  RAC  Product  Order  Form 


Name  _ 

Company  _ 

Division  _ 

Address _ 

City  _ State _ Zip 

Country  Phone  Ext. 

Method  of  Payment  ■  —  —  ■ 

□  Personal  check  enclosed 

□  Company  check  enclosed  (Make  checks  payable  to  IITRI/RAC) 


□  Credit  Card  # 

Expiration  Date 

Type  (circle): 

AMERICAN  EXPRESS 

VISA 

MASTERCARD 

Name  on  card: 

Billing  Address: 

□  DD1 155  (Government  personnel) 

□  Company  Purchase  Order 

□  Place  my  name  on  the  distribution  list  for  the  free  RAC  Journal 
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